Request: show embed links in plaintext when blocking requests

[wolftune]

I don't want YouTube tracking me, but sometimes I want to see a video. I could explore the page source but otherwise, when YouTube requests are all blocked, I can't even get the link to an embedded video at some website. I'd like to see the embed replaced with the youtube link so that I can choose to copy/paste it to a private tab or watch in mpv etc.

Right now, I often choose to let the request go through so that the video shows, but I'd rather not do that.

[yourduskquibbles]

#1899

[wolftune]

While 1899 is related, it's a one-time turning on of the actual request to the 3rd party. My request is to just bring the url from the embed in the html and present it to the end-user while not doing any 3rd-party request.

[gorhill]

Aren't you using the collapsing of blocked resources?

[wolftune]

I am using the collapsing of blocked resources as far as I know. But Given a situation like text that says "as you can see in this video:" and then I just see the next paragraph, I would like to have a single line of text that just says "youtube.com/blah" or something so that I can choose to make use of the link if I want. I don't want the whole iframe area or whatever to be used per se.

[gorhill]

How would uBO decides when something must be visually removed, while other time it must provide a placeholder with a URL?

[wolftune]

For my particular case, I'd like if any youtube or similar embedded stuff is replaced with a URL instead of embedding. But I actually think the ideal behavior systematically (for at least my type of scenario, which might be common enough) would be something like this:

• fully block and cosmetically hide everything from filter lists
• for 3rd-party requests blocked by default (the way I use the advanced mode), block requests and replace embedded stuff with URL or some other indication that something was there to be blocked

So, anything worthy of being on the block lists is just gone gone. But I get to know about what's missing that isn't on any list and is just missing because I had 3rd-party requests blocked in general…

Does that make sense?

[gorhill]

for 3rd-party requests blocked by default (the way I use the advanced mode), block requests and replace embedded stuff with URL or some other indication that something was there to be blocked

Something could be blocked by both static and dynamic filtering. For example, when blocking 3rd-party frames by default, very possible some frame-based ads on a page are then blocked because of dynamic filtering, which would also have otherwise been blocked through static filtering, but surely you do not want to see URLs for these ads.

So what you are asking is that at collapse decision time, uBO checks whether something is blocked by only dynamic filtering, which is asking to introduce a scary overhead just for that one feature.

The way it's going, I don't see how it's feasible, looks like I will have to decline.

The only viable solution that comes to mind at this point is that the user explicitly declares, through some sort of new filter syntax, that such and such URLs matching a specific pattern have to be collapsed in a specific way.

[wolftune]

the user explicitly declares, through some sort of new filter syntax, that such and such URLs matching a specific pattern have to be collapsed in a specific way.

That sounds perfectly fine to me. I'd just add that sort of declaration for the type of thing that comes up most often.

The big issue is that without this, I (and others who may end up using this collapse-but-show-url idea) will otherwise do some mix of not blocking requests overall or temporarily enabling the requests when they want to see something they're missing, and that opens them to more tracking than the approach I'm requesting.

So, your viable solution sounds good to me. Certainly, I wouldn't expect you to make it top priority or anything.

[gorhill]

Note that I will entertain working on this if and only if there seem to be a broader demand for such feature, including across different blockers, otherwise that is just a special feature order of interest to a few people -- not something into which I will invest my free time. If in some future there is still no widespread demand, I will close as declined.

Furthermore this is by no mean trivial to implement, this requires to add/modify lots of existing code paths with all the usual potential consequences. So far I am leaning strong on the declined side.

[gorhill]

Declining, by the look of it, this will never be worked on because the pile of bugs will never decrease to a point where there is time to work on such request.