@z9Z6tG5i2 What connection, under what circumstances, using which settings? What exactly makes this a big privacy issue? A few additional details would be highly appreciated.
@z9Z6tG5i2 I did in fact analyze the traffic and nothing of the sort showed up on my end. Could you please send me your traffic analysis results? That could shed some light on the issue.
This is turning into a good discussion. I don't want to throw it off topic, but I do have a quick question for @z9Z6tG5i2 : You referred to CDN's as "shit companies". I'm interested in knowing why you view the CDN's as "shit companies" and not the companies/sites that chose to use them as the problem? Aren't the sites that choose to use them the real problem?
@z9Z6tG5i2 I must say that I'm getting entirely different results and see no DNS queries for CloudFlare when blocking requests for missing resources. But even if these requests are sent out in specific cases (e.g. on certain platforms), I still don't understand how this is a big privacy issue.
I say this because DNS queries are not sent to the host you're trying to reach (CloudFlare in your case), but to a name resolution service. Also, routers tend to be quite good at caching DNS records, so hardly any of these requests should ever leave your local network. Am I missing something?
@z9Z6tG5i2 I use Linux too, so that can't be the problem. Before we continue the discussion, have you tried navigating to about:config and setting network.dns.disablePrefetch to true?
I think this is a bug because [...] Decentraleyes conflicts with NoScript and it's not NoScript fault.
Please provide some specific details instead of speculating on the matter. I'm very open to actual bugs, especially those that affect user privacy, but I just can't wrap my head around your explanation.
How would a DNS query for cdnjs.cloudflare.com be any more revealing than the DNS query for the actual address you're visiting? Why this is a problem is beyond me. I know you initially stated:
It's a big privacy issue because the propose of the addon is to block connection to those shit companies, but if the dns queries are still sent they can see our IP anyway and if they analyze they might even see we are using an addon to block them.
The CDN cannot see your IP address and your preferred DNS service (note that you can host your own) already knows what domain you're visiting. So what exactly are your additional concerns?
@z9Z6tG5i2, give examples that can be tested is what I think @Synzvato wants from you. I also don't think Decentraleyes isn't meant to block anything, but to supplement the certain content with something cleaner.
I also think that way, but bug is a bug I'm just reporting it. I guess the confusion in this issue is that there are too many facts mixed with opinions. :-)
I don't think that's the problem here. In my opinion, this simply doesn't qualify as a bug, since a bug typically disrupts an application requirement or a promised feature. Decentraleyes is meant to keep a large amount of websites from breaking when blocking requests for major delivery networks.
Nowhere does it state that it prevents traffic to your DNS provider. As far as I can tell, there are no downsides to this. If anything, the fact that these name resolution requests are sent on certain setups, and not on others, improves your privacy by distorting potential fingerprints.
It's great that you decided to report this, as this surely is interesting behavior, it's just not a bug. As a quick related tip, if you are concerned about your current DNS provider, then you might want to look into Dnsmasq for local DNS caching. It runs on routers with DD-WRT (or similar firmware).
@z9Z6tG5i2 The word you are seeking is _conflict_. There appears to be a conflict between this extension and NoScript in that there is an unintended side effect. The conflict is not so serious as to prevent the extensions from being used together, but is serious enough to create the issue you helpfully identified.
I wish I had programming knowledge to explain better my view, but Request Policy for example blocks IP and DNS regarding what is whitelisted on NoScript.
Isn't the difference here simply that RequestPolicy cancels the request where Decentraleyes redirects it to a local resource? This is comparing the results of two distinct types of actions.
@Gitoffthelawn
The word you are seeking is conflict. There appears to be a conflict between this extension and NoScript in that there is an unintended side effect.
I'm not even sure if you can call this a conflict. As far as I know, none of these three add-ons make any specific promises on DNS traffic. In essence, the absence of these specific DNS requests is a side-effect of blocking all traffic to the third parties in question. Does this alter documented behavior?
@Synzvato I think it's borderline to call it a conflict. But given that one of your users has notified you that it's not working as expected, and the reason is because of running another extension, I think it's okay to make that call.
Another term could be _side-effect, but to be honest, I think it's a little more than a side-effect, and a little less than a conflict. Maybe it's a _side-conflict, but I think that's what happens when you eat doughnuts and fried spicy wings at the same time. :-)
But given that one of your users has notified you that it's not working as expected, and the reason is because of running another extension, I think it's okay to make that call.
Expectations are personal though. I think what matters is whether or not this add-on alters documented behavior of other installed extensions (or itself). As far as I can tell, this is not the case.
I think it's a little more than a side-effect, and a little less than a conflict. Maybe it's a side-conflict, I think that's what happens when you eat doughnuts and fried spicy wings at the same time. :-)
Haha, I think you might be onto something there, since I haven't encountered any side-conflicts since the day on which I decided to kick meat out of my diet. 😜 Well, up until spotting this issue, that is.
Expectations are personal though. I think what matters is whether or not this add-on alters documented behavior of other installed extensions (or itself). As far as I can tell, this is not the case.
As a UI/UX expert, I tend to focus more on user expectations than documented functionality. Documented functionality can sometimes be based on poor specifications. User expectations, except when irrational, always form a logical tautology: they are user expectations.
In this specific case, I see the OP's concern. It got convoluted because they presented colloquial opinion with their report, but I think you finally got to the core.
Your statement "The CDN cannot see your IP address and your preferred DNS service (note that you can host your own) already knows what domain you're visiting. So what exactly are your additional concerns?" is a strong argument and is largely accurate (there are possible exceptions, but it gets into edge cases).
My response is that if you can snap your fingers or invest a small amount of time to accommodate this issue, go for it. It probably won't hurt, and may help a little. At the least, adding a FAQ note makes sense given that other users may encounter this issue.
On the other hand, if it involves a large time commitment or painful brain contortions, it may not be the best use of your time and energy. If your brain explodes, it gets messy for everyone in the room. And your cat will be forever traumatized.
Haha, I think you might be onto something there, since I haven't encountered any side-conflicts since the day on which I decided to kick meat out of my diet. 😜 Well, up until spotting this issue, that is.
That's probably why you look so healthy. I recently read a report that the best way to "save the planet" is for everyone to become a vegetarian. Some experts predict than in 50 years it will be unfathomable that so many people once ate so much meat.