The study will run for 7 days, there is a special privacy agreement with Cloudflare and only 50% of users will participate in the active group, the rest is control. The various concerns are being discussed on the bug tracker, if you don’t like something I recommend you participate.
It’s not clear to me if the ‘Developer Edition’ is considered a pre-release version for what Mozilla can do to it, but it probably is. Your only reasonably safe option appears to be to run a release version of Firefox.
For all I know, the Dev Edition is a release. It is entirely reasonable to test out new features in pre-release versions of Firefox, IMO. DoH can significantly improve the privacy of users compared to traditional DNS. I think the benefits here (increased privacy for everyone using Firefox) outweigh the downsides (perceived, potential and temporary decrease in privacy when using Firefox)
Sure, but it’s worthwhile users alerting Mozilla of the boundaries of that testing that they’re comfortable with. Yes, happy to test new features, bug fixes, new UI, etc. Not so sure about testing involving my browsing activity being sent to a private company in a foreign country.
As opposed spraying your browsing activity unencrypted, all over the internet. DNS is without a doubt the most dubious protocol in use by the average internet user, ever since unencrypted HTTP became uncool.
And the privacy policy they negotiated with CloudFlare is pretty strict:
And in this case the operating agreement with the dns provider is part of making that right choice. For this test that means the operator will not retain for themselves or sell/license/transfer to a third party any PII (including ip addresses and other user identifiers) and will not combine the data it gets from this project with any other data it might have. A small amount of data necessary for troubleshooting the service can be kept at most 24 hrs but that data is limited to name, dns type, a timestamp, a response code, and the CDN node that served it.
I’m aware of the downsides of DNS, and I’m pleased to see work towards alternatives. I would like such experiments to either be opt in, or provide ample notification that privacy expectations are different for the duration of the experiment so users can choose not to share their data with CloudFlare if they want. As Mozilla says in their recent blog post:
At Mozilla, our approach to data is simple: no surprises, and user choice is critical. We believe in that not just because it makes for good products, but because trust is a key factor in keeping the internet healthy.
Ah yes, I forgot the first principle of security, “if you can’t protect everything perfectly, might as well just protect nothing.”
DNS requests and responses leak plenty of information that an encrypted connection won’t, chiefly the domains and subdomains I’m visiting. If I’ve encrypted my DNS traffic can you still figure out what I’m doing just from the destination IP address? Yes just whois that IP address! Easy right? Oh, it’s Cloudflare. That really narrows it down, they don’t have very many customers. Or maybe Akamai, or Cloudfront, or S3, or GCS. Just knowing what CDN I sent a request to is enough to make an educated guess about what I was doing, no doubt. Cloudflare only has 6 million customers or so, should be easy to pick out the one I’m using.
If I’ve encrypted my DNS traffic can you still figure out what I’m doing just from the destination IP address?
No, you can still figure it out from SNI, which sends the domain and subdomain you’re accessing in cleartext before the TLS connection starts, this is used to allow the server to present the correct certificate.
Basically all major websites today require SNI, and your browser will send it even if the site may not require it, causing any MitM to see just as much from SNI as they would see from DNS.
There is a proposal to encrypt SNI. Sending DNS over HTTP is one of many defenses we have to put up to increase privacy, a single solution will not fix it.
Probably, yes, for such purposes you can fall back to a local resolver that can do DNS over HTTP for you or alternatively just use plain DNS.
The reason people want to jump for DNS over HTTP is that it’s least likely to break middleboxes (dnscrypt does, there were a few fun situations I had while using it with DNS manipulating middleboxes like you find in any free wifi out there)
HTTPS is rarely inspected and when it is, the body is left alone, so putting DNS there is a reasonable way to get middleboxes to stop modifying it.
Sure, that’s a solution for the people that have to deal with middleboxes.
But it would be preferable if those of us that don’t could have a simpler, more efficient protocol, for which cleaner and faster implementations can exist.
Part of this study is exactly to find out how efficient this is.
The upside is also that DoH offers privacy without clients having to massively reimplement everything.
dnscrypt has to my knowledge rather poor support and IIRC was even dropped from development entirely for a period of time, the author pointing the website towards the DoH implementation at Google.
The problem really is that the size of a UDP packet doesn’t offer much space to do much cryptography. A RSA4096 key will take up to 446 bytes, the largest UDP packet you can safely send over the internet is 500 bytes. Current DNSSEC largely relies on RSA2048 via multiple TXT records (you can hear the belt jumping from the gears when you push that into BIND, it works but bleh)
Ed25519 takes 32 bytes, which is much better, but that’s still almost 10% of the entire packet.
On DoH there is no such limitation. We can stuff more complicated and more secure cryptography through there. You can sign the entire response body with a good and long key on the origin server and put it into a header. Simple and efficient, yet safe.
I’m myself a developer for an Android client for an IRC bouncer with custom protocol.
I’ve spent quite a while to implement our custom binary protocol to get highest performance, and I can do a whole handshake - connect - sync in below 50ms on a good connection, or at a maximum of around 5 seconds on 2G throttled to 64kbps on a 2010 phone on unreliable connection with a protocol worst case.
Even establishing a HTTP/2 connection becomes a significant bottleneck at this point. (And I’ll probably have to ship a custom DNS resolver in the app anyway, as people want to be able to use mDNS resolution, which Android doesn’t support)
You don’t have to establish a HTTP/2 connection per roundtrip. You’re supposed to keep the connection open and you can then even multiplex requests over it.
Your android app should not be implementing DNS. It should be handing over the DNS requests to the system library which is then free to use DoH or traditional DNS or dnscrypt.
Application protocols like IRC are fine since they’re on a higher level but DNS shouldn’t be a problem your application has to concern itself with.
mDNS is a signficiantly simpler spec than DNS itself (once you include all the updates you need to understand all the modern queries and responses) and I don’t see why you would even begin to pipe it over DoH…
Does your DoH work in a corporate intranet, where only the local IRC server is available in the subnet the phone is in (I’ve got cases such as that)?
Does your DoH work in situations where the user can access local servers with sub 6ms RTT, but the nearest Google server is 350ms RTT away?
There’s lots of situations where these things get complicated, and this experiment will only ever be able to test a tiny subset of them. The majority of these edge cases need to be explored through other means.
That’s true, I didn’t think about SNI. Still DNS traffic probably will go someplace else other than the eventual destination server, providing more opportunities to snoop. And DNS often encodes more than just the target hostname. And there are quite a few more MitM attacks on DNS than TLS connections. So there’s definitely room for improvement in hostname resolution.
For DNS there’s a flag you can use with your local resolver to only send the relevant parts to each server.
So to resolve i.k8r.eu you’d only send “eu.” to the root DNS server, then only “k8r.eu.” to the .EU nic’s server, and only the actual DNS server of i.k8r.eu would see the full subdomain.
I opted to use nightly to help make Firefox a more stable product for people less willing to put up with crashse, and to help test certain new technologies (stylo originally, recently webrender). I did not install it with the understanding that Mozilla would feel free to share my browsing habits with a third party.
It’s unfortunate that there is not a reasonable way to help test firefox that respects your rights, but I suppose I understand why they want some channel to test things like this. Either way, I’ve now uninstalled nightly and will stick to the stable version.
Disable Shield Studies in the Preference Menu. Then you can test Firefox and not have Firefox share your browsing data with which an explicit agreement exists to not log your browsing data for anything beyond debugging purposes and 24h maximum which is used to develop DoH which massively increases user privacy.
It’s not just this study I want to avoid. It’s any similar behavior in the future, which I may or may not hear about like I did this time. As the original post points out, there doesn’t seem to be any policy in place guaranteeing that this sort of behavior will be limited to shield studies. The attitutudes displayed in the bug for this study seem to be along the lines of “if it’s not forbidden this level of invasion of privacy is fine”, so I don’t see why I would trust that setting to prevent a similar thing from happening except not as a “study”. Moreover there is an open issue about that checkbox getting reenabled, which inspires little confidence.
As for your attempt at minimizing the data shared, you’re right, it could be worse, but this is already far too much. Mozilla has no right to trust a third party like this on my behalf. Even if they did that agreement simply does not exist in the form you want it to for the simple reason that cloudflare is a US company. They do not have the power to enter into such an agreement since by law they can be required to provide that data to the US government (which, to me, is a foreign government).
And to be perfectly frank, I wouldn’t even mind opting into this study, I already use a US dns provider. But the lack of trustworthiness and respect displayed towards nightly users means I will not be one.
Again, you can opt out. The bug you mentioned is an open issue as you noted, if you’d like to see it fix, you can submit reports or code to help out.
Mozilla is not a closed organization, almost everything happens in public.
The study hasn’t even started yet, so I’m not sure why people are freaking out unless Mozilla will actually implement this as opt out (the mailing list seems to indicate otherwise)
I can opt out this time because I heard about it in advance. There is no guarantee I will hear about it in advance next time, so next time I may not be able to. Mozilla in doing this (even in seriously considering this) has clearly indicated that they do not respect the rights of nightly users.
As I read it the mailing list has everyone approving the opt out version, so I don’t think the mailing list indicates otherwise. Specifically of the 6 people who were asked to approve it, 5 already have. From context I think the last one is a lawyer checking if it’s legal? When the limit of whether or not you’re violating privacy too much is “is this literally illegal” you don’t impress me.
That fact that it’s a bug doesn’t terribly matter, it means that there isn’t even an effective way to opt out of the studies. The only proper response upon discovering that bug was halting all shield studies until they found the cause, fixed it, and alerted everyone who might have had the button automatically rechecked about it (which in practice may mean every nightly user). I’d care more about if Mozilla hadn’t already lost my trust in regards to nightly in general, and if it provided some form of meaningful consent (which it doesn’t, since it could easily have remained check simply by me not hearing about it or realizing what it meant).
The opt out is not per study, you can opt out of any shield studies. And as others have noted, Nightly is not for production. It is playground for Mozilla where they test exactly these kinds of features.
If you run Beta software, be prepared that it does things you wouldn’t expect.
I’m still fairly convinced people are simply overreacting over simple A/B tests to improve privacy of Firefox proper.
The opt out is not per study, but it is per feature. I see no reason to believe that the only way Mozilla will do things like this is through shield studies when none of their policies indicate that this is the case. It is also not clearly communicated what the opt out is for - assuming it has the same text above it as in firefox stable (I have uninstalled nightly already and didnt check first) it says immediately above it that “We always ask permission before receiving personal information”, which is plainly not the case here.
I expected nightly to be buggy, to crash sometimes, and maybe to not work at all once in awhile. That was about the case (surprisingly unbuggy without enabling things like webrednder.enabled.all actually). I did not expect nightly to intentionally violate my privacy.
As I said at the start, maybe I just misunderstood what nightly is for, either way I’m not going to continue using it.
Mozilla explicitly notes in their privacy page that Nightly will have different privacy characteristica than the normal distribution, so no it’s not simply “the same text”.
If you value privacy you should not be using a pre-beta release of a software meant for (A/B) testing latest features.
This specific study is Nightly only. In general I’d expect and hope that similar studies would only be run against Nightly for various reasons. However, as far as I can tell the current Mozilla privacy policy makes no difference between Nightly and Beta, and therefore Mozilla could consider themselves to have permission to run these opt-out studies on Beta, just as they have with Nightly. Mozilla may clarify this in the future.
On a pragmatic level, doing something like this with Beta would probably be much more visible and produce many more annoyed people and bad publicity, so I think Mozilla probably has good reasons to avoid it unless they have a study that they consider really important. Beta also has enough visibility that news about such an opt-in study would probably be widely distributed and well know, so you’d hear of it enough in advance to do something.
Thanks for this. I’ve been running Nightly on my mobile, and I’ve switched to Beta. (Newer Firefox versions than Stable on Android seem quite a bit faster; that’s why I care.)
It seems like it should be possible to find a DNS provider that already exists to host them, and then only test on users who already use that DNS provider.
Let me amend what I said: There are no DoH servers out there except for the one Mozilla set up. DoH isn’t even a standard yet. It’s a draft proposal to the IETF.
That doesn’t change what I said. Instead of partering with cloudflare to have them implement this/run servers providing it, partner with someone who already provides DNS to a substantial number of users. Either way you are requring someone to implement new technology, this is just changing who that someone is.
It’s a change, but it would only matter if you trust Cloudflare to see a significant fraction of your traffic, but are not ok with them seeing all your DNS queries. I can’t fathom how that makes sense.
Privacy fanatics are getting more and more annoying. I think stuff like that makes privacy advocacy actually less effective. If you start complaining loudly about things like a DNS replacement in an experimental testing browser, people will take you (and in general, the whole privacy thing) less seriously.
one of the worst companies for the Internet in 2018
Definitely not an overreaction at all when we consider what other companies do as SOP. The point is that there has been pushback against Mozilla every time one of these exceptional events has occurred.
I honestly don’t understand why the “use my custom WebKit-based browser” people can’t be just a little more rational.
I think it’s part and parcel of the techie personality. Companies are either Good or Evil. Because Mozilla has made decisions they disagree with, and which violate some sort of open source Purity of Essence, they are now Evil and should be shunned.
I’d argue that this is exactly the wrong behavior to enact and that instead we should be using Firefox and guiding Mozilla in the right direction. Firefox is pretty much the only game in town that’s an open source alternative AND has significant market share. That means something, unless we want to just abandon ship and let Google and Microsoft win utterly.
Wow, who at Mozilla hurt you? Definitely Mozilla has problems, which is while the rest of us criticize them rationally. Then, like I said, invariably the “custom WebKit browser” people come in and say stuff like this.
For reference, here are the actual details on the study; https://bugzilla.mozilla.org/show_bug.cgi?id=1446404
The study will run for 7 days, there is a special privacy agreement with Cloudflare and only 50% of users will participate in the active group, the rest is control. The various concerns are being discussed on the bug tracker, if you don’t like something I recommend you participate.
For all I know, the Dev Edition is a release. It is entirely reasonable to test out new features in pre-release versions of Firefox, IMO. DoH can significantly improve the privacy of users compared to traditional DNS. I think the benefits here (increased privacy for everyone using Firefox) outweigh the downsides (perceived, potential and temporary decrease in privacy when using Firefox)
Yes, that’s what testing means, among other things. Nightlies are for testing.
Sure, but it’s worthwhile users alerting Mozilla of the boundaries of that testing that they’re comfortable with. Yes, happy to test new features, bug fixes, new UI, etc. Not so sure about testing involving my browsing activity being sent to a private company in a foreign country.
As opposed spraying your browsing activity unencrypted, all over the internet. DNS is without a doubt the most dubious protocol in use by the average internet user, ever since unencrypted HTTP became uncool.
And the privacy policy they negotiated with CloudFlare is pretty strict:
I’m aware of the downsides of DNS, and I’m pleased to see work towards alternatives. I would like such experiments to either be opt in, or provide ample notification that privacy expectations are different for the duration of the experiment so users can choose not to share their data with CloudFlare if they want. As Mozilla says in their recent blog post:
So, pray tell, what do I use to replace DNS?
Saying that about DNS might make more sense if more people ran their own DNS server, instead of relying upon their ISP or worse, Google.
…this DNS replacement technology that Mozilla is testing out in their nightly.
Wonderful! Why not run IP over HTTPS/2?
You are still spraying your browser activity over the Internet, only the contents are protected, not who you are visiting.
Ah yes, I forgot the first principle of security, “if you can’t protect everything perfectly, might as well just protect nothing.”
DNS requests and responses leak plenty of information that an encrypted connection won’t, chiefly the domains and subdomains I’m visiting. If I’ve encrypted my DNS traffic can you still figure out what I’m doing just from the destination IP address? Yes just whois that IP address! Easy right? Oh, it’s Cloudflare. That really narrows it down, they don’t have very many customers. Or maybe Akamai, or Cloudfront, or S3, or GCS. Just knowing what CDN I sent a request to is enough to make an educated guess about what I was doing, no doubt. Cloudflare only has 6 million customers or so, should be easy to pick out the one I’m using.
No, you can still figure it out from SNI, which sends the domain and subdomain you’re accessing in cleartext before the TLS connection starts, this is used to allow the server to present the correct certificate.
Basically all major websites today require SNI, and your browser will send it even if the site may not require it, causing any MitM to see just as much from SNI as they would see from DNS.
There is a proposal to encrypt SNI. Sending DNS over HTTP is one of many defenses we have to put up to increase privacy, a single solution will not fix it.
Trust, but it’d be preferable to send DNS over a simpler protocol, e.g. what dnscrypt did.
DNS over HTTP makes DNS resolution on e.g. an Arduino basically impossible, because you’re now using half of your ROM for the TCP and HTTP stack.
Probably, yes, for such purposes you can fall back to a local resolver that can do DNS over HTTP for you or alternatively just use plain DNS.
The reason people want to jump for DNS over HTTP is that it’s least likely to break middleboxes (dnscrypt does, there were a few fun situations I had while using it with DNS manipulating middleboxes like you find in any free wifi out there)
HTTPS is rarely inspected and when it is, the body is left alone, so putting DNS there is a reasonable way to get middleboxes to stop modifying it.
Sure, that’s a solution for the people that have to deal with middleboxes.
But it would be preferable if those of us that don’t could have a simpler, more efficient protocol, for which cleaner and faster implementations can exist.
Part of this study is exactly to find out how efficient this is.
The upside is also that DoH offers privacy without clients having to massively reimplement everything.
dnscrypt has to my knowledge rather poor support and IIRC was even dropped from development entirely for a period of time, the author pointing the website towards the DoH implementation at Google.
The problem really is that the size of a UDP packet doesn’t offer much space to do much cryptography. A RSA4096 key will take up to 446 bytes, the largest UDP packet you can safely send over the internet is 500 bytes. Current DNSSEC largely relies on RSA2048 via multiple TXT records (you can hear the belt jumping from the gears when you push that into BIND, it works but bleh)
Ed25519 takes 32 bytes, which is much better, but that’s still almost 10% of the entire packet.
On DoH there is no such limitation. We can stuff more complicated and more secure cryptography through there. You can sign the entire response body with a good and long key on the origin server and put it into a header. Simple and efficient, yet safe.
I’m myself a developer for an Android client for an IRC bouncer with custom protocol.
I’ve spent quite a while to implement our custom binary protocol to get highest performance, and I can do a whole handshake - connect - sync in below 50ms on a good connection, or at a maximum of around 5 seconds on 2G throttled to 64kbps on a 2010 phone on unreliable connection with a protocol worst case.
Even establishing a HTTP/2 connection becomes a significant bottleneck at this point. (And I’ll probably have to ship a custom DNS resolver in the app anyway, as people want to be able to use mDNS resolution, which Android doesn’t support)
You don’t have to establish a HTTP/2 connection per roundtrip. You’re supposed to keep the connection open and you can then even multiplex requests over it.
Your android app should not be implementing DNS. It should be handing over the DNS requests to the system library which is then free to use DoH or traditional DNS or dnscrypt.
Application protocols like IRC are fine since they’re on a higher level but DNS shouldn’t be a problem your application has to concern itself with.
mDNS is a signficiantly simpler spec than DNS itself (once you include all the updates you need to understand all the modern queries and responses) and I don’t see why you would even begin to pipe it over DoH…
The question with all this is, to where?
Does your DoH work in a corporate intranet, where only the local IRC server is available in the subnet the phone is in (I’ve got cases such as that)?
Does your DoH work in situations where the user can access local servers with sub 6ms RTT, but the nearest Google server is 350ms RTT away?
There’s lots of situations where these things get complicated, and this experiment will only ever be able to test a tiny subset of them. The majority of these edge cases need to be explored through other means.
Yes because DoH is a protocol, you don’t have to send it to a Google server.
Since it’s simply DNS piped over HTTP you can pipe the HTTP body into any DNS server and get a response over localhost.
DoH only means “open a HTTP connection, pipe dns query into the body”. HTTP/2 deals with multiplexing and keep-alive.
And you can still have local resolution via /etc/hosts or mDNS, those are seperate resolvers.
That’s true, I didn’t think about SNI. Still DNS traffic probably will go someplace else other than the eventual destination server, providing more opportunities to snoop. And DNS often encodes more than just the target hostname. And there are quite a few more MitM attacks on DNS than TLS connections. So there’s definitely room for improvement in hostname resolution.
For DNS there’s a flag you can use with your local resolver to only send the relevant parts to each server.
So to resolve i.k8r.eu you’d only send “eu.” to the root DNS server, then only “k8r.eu.” to the .EU nic’s server, and only the actual DNS server of i.k8r.eu would see the full subdomain.
I opted to use nightly to help make Firefox a more stable product for people less willing to put up with crashse, and to help test certain new technologies (stylo originally, recently webrender). I did not install it with the understanding that Mozilla would feel free to share my browsing habits with a third party.
It’s unfortunate that there is not a reasonable way to help test firefox that respects your rights, but I suppose I understand why they want some channel to test things like this. Either way, I’ve now uninstalled nightly and will stick to the stable version.
Disable Shield Studies in the Preference Menu. Then you can test Firefox and not have Firefox share your browsing data with which an explicit agreement exists to not log your browsing data for anything beyond debugging purposes and 24h maximum which is used to develop DoH which massively increases user privacy.
It’s not just this study I want to avoid. It’s any similar behavior in the future, which I may or may not hear about like I did this time. As the original post points out, there doesn’t seem to be any policy in place guaranteeing that this sort of behavior will be limited to shield studies. The attitutudes displayed in the bug for this study seem to be along the lines of “if it’s not forbidden this level of invasion of privacy is fine”, so I don’t see why I would trust that setting to prevent a similar thing from happening except not as a “study”. Moreover there is an open issue about that checkbox getting reenabled, which inspires little confidence.
As for your attempt at minimizing the data shared, you’re right, it could be worse, but this is already far too much. Mozilla has no right to trust a third party like this on my behalf. Even if they did that agreement simply does not exist in the form you want it to for the simple reason that cloudflare is a US company. They do not have the power to enter into such an agreement since by law they can be required to provide that data to the US government (which, to me, is a foreign government).
And to be perfectly frank, I wouldn’t even mind opting into this study, I already use a US dns provider. But the lack of trustworthiness and respect displayed towards nightly users means I will not be one.
Again, you can opt out. The bug you mentioned is an open issue as you noted, if you’d like to see it fix, you can submit reports or code to help out.
Mozilla is not a closed organization, almost everything happens in public.
The study hasn’t even started yet, so I’m not sure why people are freaking out unless Mozilla will actually implement this as opt out (the mailing list seems to indicate otherwise)
I can opt out this time because I heard about it in advance. There is no guarantee I will hear about it in advance next time, so next time I may not be able to. Mozilla in doing this (even in seriously considering this) has clearly indicated that they do not respect the rights of nightly users.
As I read it the mailing list has everyone approving the opt out version, so I don’t think the mailing list indicates otherwise. Specifically of the 6 people who were asked to approve it, 5 already have. From context I think the last one is a lawyer checking if it’s legal? When the limit of whether or not you’re violating privacy too much is “is this literally illegal” you don’t impress me.
That fact that it’s a bug doesn’t terribly matter, it means that there isn’t even an effective way to opt out of the studies. The only proper response upon discovering that bug was halting all shield studies until they found the cause, fixed it, and alerted everyone who might have had the button automatically rechecked about it (which in practice may mean every nightly user). I’d care more about if Mozilla hadn’t already lost my trust in regards to nightly in general, and if it provided some form of meaningful consent (which it doesn’t, since it could easily have remained check simply by me not hearing about it or realizing what it meant).
The opt out is not per study, you can opt out of any shield studies. And as others have noted, Nightly is not for production. It is playground for Mozilla where they test exactly these kinds of features.
If you run Beta software, be prepared that it does things you wouldn’t expect.
I’m still fairly convinced people are simply overreacting over simple A/B tests to improve privacy of Firefox proper.
The opt out is not per study, but it is per feature. I see no reason to believe that the only way Mozilla will do things like this is through shield studies when none of their policies indicate that this is the case. It is also not clearly communicated what the opt out is for - assuming it has the same text above it as in firefox stable (I have uninstalled nightly already and didnt check first) it says immediately above it that “We always ask permission before receiving personal information”, which is plainly not the case here.
I expected nightly to be buggy, to crash sometimes, and maybe to not work at all once in awhile. That was about the case (surprisingly unbuggy without enabling things like
webrednder.enabled.allactually). I did not expect nightly to intentionally violate my privacy.As I said at the start, maybe I just misunderstood what nightly is for, either way I’m not going to continue using it.
Mozilla explicitly notes in their privacy page that Nightly will have different privacy characteristica than the normal distribution, so no it’s not simply “the same text”.
If you value privacy you should not be using a pre-beta release of a software meant for (A/B) testing latest features.
Is this likely to also apply to to Firefox Beta? Or does it just seem to be a Nightly thing?
This specific study is Nightly only. In general I’d expect and hope that similar studies would only be run against Nightly for various reasons. However, as far as I can tell the current Mozilla privacy policy makes no difference between Nightly and Beta, and therefore Mozilla could consider themselves to have permission to run these opt-out studies on Beta, just as they have with Nightly. Mozilla may clarify this in the future.
On a pragmatic level, doing something like this with Beta would probably be much more visible and produce many more annoyed people and bad publicity, so I think Mozilla probably has good reasons to avoid it unless they have a study that they consider really important. Beta also has enough visibility that news about such an opt-in study would probably be widely distributed and well know, so you’d hear of it enough in advance to do something.
(I’m the author of the article.)
Thanks for this. I’ve been running Nightly on my mobile, and I’ve switched to Beta. (Newer Firefox versions than Stable on Android seem quite a bit faster; that’s why I care.)
Since Cloudflare serves an inordinate amount of Internet traffic, I’m not sure this changes much.
If I understood correctly, this sends all hostnames to Cloudflare, not just those served by Cloudflare. I think it is a significant change.
Not many DoH servers out there. Somebody has to host them.
It seems like it should be possible to find a DNS provider that already exists to host them, and then only test on users who already use that DNS provider.
Let me amend what I said: There are no DoH servers out there except for the one Mozilla set up. DoH isn’t even a standard yet. It’s a draft proposal to the IETF.
Google has a DoH server, not sure how compliant with the draft though.
Meanwhile Yandex has a DNSCrypt server (and client in their browser).
That doesn’t change what I said. Instead of partering with cloudflare to have them implement this/run servers providing it, partner with someone who already provides DNS to a substantial number of users. Either way you are requring someone to implement new technology, this is just changing who that someone is.
It’s a change, but it would only matter if you trust Cloudflare to see a significant fraction of your traffic, but are not ok with them seeing all your DNS queries. I can’t fathom how that makes sense.
Privacy fanatics are getting more and more annoying. I think stuff like that makes privacy advocacy actually less effective. If you start complaining loudly about things like a DNS replacement in an experimental testing browser, people will take you (and in general, the whole privacy thing) less seriously.
[Comment removed by author]
Definitely not an overreaction at all when we consider what other companies do as SOP. The point is that there has been pushback against Mozilla every time one of these exceptional events has occurred.
I honestly don’t understand why the “use my custom WebKit-based browser” people can’t be just a little more rational.
I think it’s part and parcel of the techie personality. Companies are either Good or Evil. Because Mozilla has made decisions they disagree with, and which violate some sort of open source Purity of Essence, they are now Evil and should be shunned.
I’d argue that this is exactly the wrong behavior to enact and that instead we should be using Firefox and guiding Mozilla in the right direction. Firefox is pretty much the only game in town that’s an open source alternative AND has significant market share. That means something, unless we want to just abandon ship and let Google and Microsoft win utterly.
[Comment removed by author]
Wow, who at Mozilla hurt you? Definitely Mozilla has problems, which is while the rest of us criticize them rationally. Then, like I said, invariably the “custom WebKit browser” people come in and say stuff like this.
[Comment removed by author]
Nice job editing your comment from saying “f*ck off”.
Please don’t encourage people to use browsers which don’t get security updates on most platforms.