Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
decentraleyes
decentraleyes
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 86
    • Issues 86
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 9
    • Merge Requests 9
  • Operations
    • Operations
    • Incidents
  • Analytics
    • Analytics
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar

Microsoft has acquired GitHub. Decentraleyes has left GitHub. Welcome to its new home!

To participate, please register, or sign in with an existing GitLab.com, Bitbucket, or GitHub account.

Past contributions on GitHub? Be sure to reclaim your Comments, Issues, and Pull Requests.

  • Thomas Rientjes
  • decentraleyesdecentraleyes
  • Issues
  • #259

Closed
Open
Opened Mar 09, 2018 by Ghost User@ghostContributor

Deeply integrate with regular content blockers

Created by: hackel

I've read this entry in the FAQ: Why doesn't it deliver resources from CDNs I block using a different add-on? and it left me not very satisfied. With the suggested configuration, any requests for files from the domains listed that Decentraleyes does not have a local copy of will be silently denied. Since Decentraleyes does not have an appropriate UI for highlighting these blocked resources, one would have to resort to searching the code or network log to find them, evaluate the content of the links, and choose whether to whitelist the site in Decentraleyes or not. This is an unnecessarily complicated process.

I would like an option to flip the precedence, if possible. If this option is enabled, then Decentraleyes will allow all of its local resources through, regardless of the setting in my blocker (Ublock Origin). If they aren't available locally, then Decentraleyes will attempt to download it, and that request will in turn be caught by Ublock Origin (or uMatrix, NoScript, etc.) and shown in its UI, allowing me to choose whether or not to accept the request.

If this level of interoperability isn't possible with WebExtensions, I propse advocating for it to be added, as it would be incredibly useful. The other alternative would be for Decentraleyes to implement its own blocking UI to allow the user to choose what to allow, and that seems entirely out of the scope of this wonderful set-it-and-forget-it extension.

Edited Jun 29, 2018 by Thomas Rientjes
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: Synzvato/decentraleyes#259