-
Notifications
You must be signed in to change notification settings - Fork 119
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: Browser-level element hiding #318
Comments
+1 |
It's an interesting idea, although I'm currently against it for a couple of reasons: Implementation difficulties
I'm not 100% sure what's envisioned for the empty space left by hidden elements, but I see two potential options:
Applicability to the broader community
If such a syntax/feature were to be developed, there's no chance it'd be useful to anyone other than Brave at the moment. The wider adblocking community uses extensions. Such a capability will require deep integration with the renderer process. That isn't even possible on Mv2 extensions, let alone Mv3. I'd prefer to work on solutions that reduce, rather than increase, the fragmentation in the space already so that we can share more of the filter list development effort. I'm reminded of a previous capability in |
Certainly, as you mentioned the difficulties in altering the page layout, having only this functionality would benefit ad-blocking on persistent websites that constantly find various ways to detect modifications made by ad blockers. You may consider this as a hypothetical scenario, but @MasterKia was consistently trying to hide ads on a website and facing constant challenges. He even developed his own user script and extension, yet, as you mentioned, the extension API lacks in this regard. Therefore, I believe that this new API, which excludes an element from rendering, should only be used in the most extreme cases, and we already have such cases.
I don't mean to be rude or anything, but why would Brave want to be just another mainstream browser? In my opinion, this feature alone could attract many new users to Brave due to its more professional ad-blocking capabilities. I understand that deviating from the standard set by mv3 may not seem like a good idea, but this custom browser implementation could potentially inspire other major players like Mozilla to adopt a similar approach or improve upon the idea. However, every great initiative has to start somewhere. |
Just to show how many sites do this already:
Most of these sites also using heavy script obfuscation, tampering/integrity checks, randomized function and variable names or even a tight CSP to hinder execution of scriptlets and custom userscripts. |
Currently sites can easily detect if elements (e.g. ads) are hidden (
display: none
,clip-path: circle(0)
, etc) using "getComputedStyle".I did spoof the result of "getComputedStyle" using a Proxy and
object.defineProperty
but sites can still detect object tampering.So my proposal is browser-level element hiding:
Instead of "hiding" the element, add an option to prevent an element from rendering to the user's screen and GPU.
This way, sites can't detect hidden elements using Javascript.
The text was updated successfully, but these errors were encountered: