search

Synzvato / decentraleyes

This repository has a new home: https://git.synz.io/Synzvato/decentraleyes
Mozilla Public License 2.0
1.45k stars 108 forks source link

Conflicts with Greasemonkey script dependencies #120

Closed rmenessec closed 7 years ago

rmenessec commented 8 years ago

Unfortunately, there doesn't seem to be any way to prevent this by modifying preferences. Even attempting to create a new userscript with a conflicting dependency will cause Greasemonkey to fail to load the external dependency with 'unknown error'.

Example: Direct Google (modified by rickzabel)

L-a-n-g-o-l-i-e-r-s commented 7 years ago

Dependencies as in say, jquery-2.0.3.min.js being included in say AntiAdware script resources? Or something else entirely? For clarification purposes.

rmenessec commented 7 years ago

@L-a-n-g-o-l-i-e-r-s , If memory serves, that particular userscript was trying to load jQuery 3.0.0-alpha (alpha-1?) from jQuery.com.

I uninstalled the userscript because it ended up annoying me for unrelated reasons, so I would have to go back and reinstall it to be sure which version. I am sure it was jQuery, and I'm sure it was hosted at jQuery.com.

While I'm thinking of it: it would be a really good idea to add some form of optional, probably off by default, notification from Decentraleyes when resources are blocked. Something like a uBlock Origin "blocked resources count" badge would be great and unobtrusive. At minimum, logging to the developer console.

At present, when Decentraleyes blocks a resource, there's no indication at all; I tried walking up the URL to compare, and I couldn't load a single thing until I finally hit the root of jQuery.com. There was no indication as to why; Firefox simply failed to react in any visible way when I pressed Return. I finally thought of Decentraleyes shortly before resorting to starting Firefox in Safe Mode...

L-a-n-g-o-l-i-e-r-s commented 7 years ago

@rmenessec not a bad idea, I think if they go that route, an option to make a notification more passive without a toast, like with an icon that changes color or something.

Additionally AntiAdware has a copy of jquery-2.0.3.min.js sitting in its folder with the script its self, seems to work alright, but my copy of decentraleyes was botched so I haven't tested to see now that it's working again.

Synzvato commented 7 years ago

@rmenessec Thanks for the heads-up, and thank you @L-a-n-g-o-l-i-e-r-s for jumping in! I'll be marking this as an observation. I'm happy to say that work has started on an improved user interface.

L-a-n-g-o-l-i-e-r-s commented 7 years ago

@Synzvato Exciting! I haven't had any difficulties that I'm aware of with userscripts, atleast with the example I mentioned since I switched back to the official build all those months ago. OP should comment if this is still an ongoing issue.

I hope the interface will be immune to the coming changes, it's hard to get enthusiastic about updating Firefox any more :ear_of_rice: , granted I know things are being done in the name of hardening the security etc.

rmenessec commented 7 years ago

@L-a-n-g-o-l-i-e-r-s , no changes have been made that I'm aware of that would fix the conflict with Greasemonkey. Please don't make suggestions about whether bugs should be closed unless you have evidence that the original cause has been repaired.

@Synzvato I'm confused. Why is this closed, and how are UI improvements related to fixing the conflict with Greasemonkey? In addition to breaking Greasemonkey, this bug has the potential to break any other addon with external dependencies, and potentially even addons that bundle their own.

Until Decentraleyes is guaranteed not to break other addons, I've removed it, and will not be reporting additional issues.

Synzvato commented 7 years ago

@rmenessec

I'm confused. Why is this closed [...]?

This issue is closed because no one has so far (despite our best efforts) been able to reproduce your situation. That's why this was not labeled as a reproducible bug, but as an observation. On top of all this, Decentraleyes is undergoing major rewrites, and Greasemonkey's future is uncertain at this point.

[...] and how are UI improvements related to fixing the conflict with Greasemonkey?

They're not, but since you brought them up, I figured it would be nice to provide you with some details.

Until Decentraleyes is guaranteed not to break other addons, I've removed it [...].

I do not think there is any software out there that comes with a "free-from-bugs" guarantee. In any case, it's a promise we (as a community) cannot make. Thanks again for contributing, and all the best.

L-a-n-g-o-l-i-e-r-s commented 7 years ago

@rmenessec I made no such suggestion and I said that you should comment if it's still an issue so that it can be re-opened, not closed, I was referring to @Synzvato "...I'm happy to say that work has started on an improved user interface." Firefox will be dropping XUL extension support in favor of webextension garbo from chromium to harden security, little to no support would be given via shim or otherwise to extensions that have user interfaces, I am unsure if this is still the case as I have not been in the loop for some time on the issue, so sorry if I'm spreading old information.

His reply is related to your comment about proposed user interface changes for the extension on Sep 16 2016, perhaps he was insinuating there would be a counter such as uMatrix or uBlock uses to indicate it's intercepting.

I'm sorry to hear you stopped using the extension, I won't be commenting further on this issue unless I experience the same difficulties in the future.

Synzvato commented 7 years ago

@L-a-n-g-o-l-i-e-r-s

Firefox will be dropping XUL extension support in favor of webextension [...] to harden security, little to no support would be given via shim or otherwise to extensions that have user interfaces [...].

That's absolutely true. Building a user interface on top of deprecated technologies would be a waste of time. That's why the new user interface is being built on top of our new, experimental, foundation.

rmenessec commented 7 years ago

@Synzvato ,

This issue is closed because no one has so far (despite our best efforts) been able to reproduce your situation.

Okay. There was no mention of efforts to reproduce, so I was puzzled that the issue was simply marked closed with no further comment. And, to clarify in advance, I mean that no one directly associated with the project mentioned attempts to test.

@L-a-n-g-o-l-i-e-r-s says (emphasis mine):

[...] but my copy of decentraleyes was botched so I haven't tested to see now that it's working again.

...Which seems to mean that s/he did not perform testing of this issue, either.

I do not think there is any software out there that comes with a "free-from-bugs" guarantee. In any case, it's a promise we (as a community) cannot make.

Sorry, I should have been clearer: I meant "Until I receive news that some fix has been applied to solve this issue." I'm aware that there's no such thing as perfectly bug-free software. However, Decentraleyes hasn't—so far as I can tell—seen any commits to address this issue. I think it's fair to assume that it hasn't been fixed by accident, either.

I would be happy to re-test if Decentraleyes gets code that protects requests from other extensions from being blocked, or some other solution with a similar effect. No matter what happens to Greasemonkey, Decentraleyes should not interfere with the operation of other addons, and Greasemonkey is far from the only Firefox addon that can or does retrieve resources from the web.

As an example, Ghostery, a hugely popular addon, has moved its entire UI out of the addon, to a website. This sets up a scenario in which Decentraleyes might cripple Ghostery's UI.

L-a-n-g-o-l-i-e-r-s commented 7 years ago

@rmenessec I just installed the example you listed and went to google.com, searched "computer monitor" and clicked shopping, I got an unresponsive script error box popping up, my browser slowed to a crawl, I've not seen "external error" or "load dependency", but it certainly said jsquery.js.

I'm not entirely sure why AdAware still works, perhaps it's because it lists jquery-2.0.3.min.js (at the time) rather than just jsquery.js, could that be some of the problem @Synzvato?

I've had this vary rarely but assumed it was simply a bug with a script. Please re-open the issue and confirm it @Synzvato .

Synzvato commented 7 years ago

@rmenessec Thanks for clarifying your earlier remarks. I have indeed not been too clear about the fact that I've been attempting to reproduce the issue. During my debug-session, no breakpoints were hit.

@L-a-n-g-o-l-i-e-r-s I have played around with it before in an attempt to reproduce the issue. It did stall on me during various tries, but has also done so with Decentraleyes disabled. I need to be sure that this is indeed caused by Decentraleyes before I can mark this as being a (reproducible) bug.

What we need is a reliable way of reproducing and debugging this issue. First, we need to prove that this is indeed caused by this extension (as, so far, I've been unable to). Additional details are welcome.

Synzvato commented 7 years ago

@L-a-n-g-o-l-i-e-r-s Could you please disable Decentraleyes, restart your browser, and try again? I am experiencing the exact same page freezing issues after disabling the extension.

rmenessec commented 7 years ago

@Synzvato Do you need additional details from me? I hope my original description had enough information to work with.

I can still reproduce this problem using "Direct Google (modified by rickzabel)" as an exemplar: gfork_install_error

If I disable Decentraleyes again, I can install the script immediately, without even needing to restart the browser.

I created a gist with about:support contents from Firefox on the machine where I'm presently reproducing this.

Synzvato commented 7 years ago

@rmenessec Try disabling "Block requests for missing resources". The screenshot is not illustrating a bug, but expected behavior. You're actively blocking all remote content from known CDNs.

rmenessec commented 7 years ago

@Synzvato Now, that's odd. I had "Block requests" quite purposely disabled before now. When I looked just now, it was enabled.

I've had Decentraleyes disabled since shortly after I filed the bug... Do either Decentraleyes or Firefox modify addon preferences if an addon is disabled? I can't point to an example, but I believe I've seen that kind of behavior before.

On another machine, I believe I uninstalled Decentraleyes entirely, and reinstalled it later when I wanted to try to reproduce the problem on multiple machines. (I was able to reproduce the problem. I never checked to see whether "Block requests" had been re-enabled somehow.)

EDIT: By the way, what's the default behavior on a first install of Decentraleyes? I can't remember.

EDIT 2: Never mind. At least according to the "see if you can reset it in about:config" test, Firefox thinks the default should be no blocking. Now I'm very confused about how it ended up enabled. The only addons I have installed that attempt to manage userprefs they don't own are things like Classic Theme Restorer or Tab Mix Plus; nothing that modifies other extensions' userprefs. ...Not as an advertised feature, at least.

TriMoon commented 7 years ago

if Decentraleyes gets code that protects requests from other extensions from being blocked, or some other solution with a similar effect.

I sure hope this won't be a default feature that's enabled without a user setting in the UI.... It would enable other extensions from bypassing the functionality of DecentralEyes that the user wanted...

rmenessec commented 7 years ago

@TriMoon

if Decentraleyes gets code that protects requests from other extensions from being blocked, or some other solution with a similar effect.

I sure hope this won't be a default feature that's enabled without a user setting in the UI.... It would enable other extensions from bypassing the functionality of DecentralEyes that the user wanted...

In principle, I agree that this is something that end users should be able to see and to control. However, if your concern is that you have addons installed that you think are spying on you, the solution isn't to install Decentraleyes to protect you; it's to remove the addon that can't be trusted.

The alternative is trying to protect the end user from themselves in an infinitely-escalating arms race that results in unworkable and even malignant "solutions" like extensions that can't remap keys (Chrome) or mandatory signed addons unless you're willing to do all your browsing with alpha builds (Firefox).

TriMoon commented 7 years ago

@rmenessec

In principle, I agree that this is something that end users should be able to see and to control. However, if your concern is that you have addons installed that you think are spying on you, the solution isn't to install Decentraleyes to protect you; it's to remove the addon that can't be trusted.

I was refering to extensions that make use of external CDN's... (Because that's the context of this extension)

rmenessec commented 7 years ago

@TriMoon

I was refering to extensions that make use of external CDN's... (Because that's the context of this extension)

Yes and no.

Yes, I understood what you were referring to. But, no, nothing in the description or documentation of this addon indicates that its purpose is to regulate the operation of other addons. None of the addons I actually use (I threw out Ghostery months ago) perform any sort of tracking that isn't opt-in, opt-out, or generally intended to improve the development of the extension (like Firefox' various 'telemetry' options) rather than for malicious purposes.

If the purpose of Decentraleyes really is to keep untrustworthy addons from tracking you: again, that's a lost battle. Not losing: lost. Two addons operating in the same browser have access to the same resources, and if Decentraleyes ever seriously takes off and becomes widely used, untrustworthy addons will adapt in the same way other malvertising tech has. Here are a few trivial-to-implement possibilities:

This is far from comprehensive, of course.

The only valid threat from which Decentraleyes can possibly protect us is from unprivileged resources loaded from the web, which I'm reasonably sure is the actual purpose of Decentraleyes.

TriMoon commented 7 years ago

@rmenessec , you should step away from your thought train about Decentraleyes trying to make things saver for the user or prevent tracking... It's purpose is about preventing unnecessary fetches to CDN provided files by proving them locally. In an attempt to save bandwidth for the user...

THATS why i posted what i wrote in https://github.com/Synzvato/decentraleyes/issues/120#issuecomment-287944061 To make things saver we have other tools like uMatrix etc etc...

Synzvato commented 7 years ago

@TriMoon I don't think @rmenessec should step away from his initial thoughts. The primary goals of Decentraleyes are to improve online privacy, and to make people less dependent on invisible third parties when browsing the web. Saving bandwidth is icing on the cake, but not the main goal of the project:

Protects you against tracking through "free", centralized, content delivery. It prevents a lot of requests from reaching networks like Google Hosted Libraries, and serves local files to keep sites from breaking. Complements regular content blockers.

Source: Add-on description.

rmenessec commented 7 years ago

@Synzvato Thank you.

TriMoon commented 7 years ago

@Synzvato , ok it wasn't the reason why I personally used it for though 😸 Because as i stated before i use other tools in place that address the privacy part with specialization on a specific aspect 😛

fe.: 1) My local DNS-Server (Bind9)

Anyway sorry to divert the discussion, back to topic pls 😇