GNOME Bugzilla – Bug 707694
Change keyword-search-url to use HTTPS
Last modified: 2014-01-09 00:01:56 UTC
The new DuckDuckGo search is great! However, I noticed that it uses http rather than https in the URL, and then redirects to https as soon as I search. I guess that it should just be https by default. As the string is translatable, I suppose this would be a string break, so it might not be important enough to ask for the break, and just delay it until 3.11.
Created attachment 254351 [details] [review] use https in the default search url
I don't think this is a reasonable default. It could be the case that some users are unable to access the port 443 because their ISP is blocking it or any other reason.
Is there no way to detect whether port 443 is blocked and provide a fallback? In the large majority of cases, using https will work just fine and protect the user's privacy better.
That would be a change that would go beyond switching the default search url. Would we do that only for duckduckgo or for any search engine set by the user? And who guarantees that, in the latter case, the ports 443 and 80 deliver the same? It all seems to me like it would either be a gross hack (for DDG) or something likely to break with other search engines or other use cases. I might be missing something, of course.
Review of attachment 254351 [details] [review]: The patch is not right, btw. You also need to change the gsettings schema and many other places where the default search engine is defined. Not that this means that I am endorsing this patch in any way :)
I think the right thing to do here would be to make Ephy implement https-everywhere: https://www.eff.org/https-everywhere
... and there is HSTS too: http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security .
(In reply to comment #6) > I think the right thing to do here would be to make Ephy implement > https-everywhere: https://www.eff.org/https-everywhere Sounds good to me! I'm already using the HTTPS Everywhere extension when I'm using Firefox and it works perfectly, as far as I can determine.
(In reply to comment #4) > That would be a change that would go beyond switching the default search url. > Would we do that only for duckduckgo or for any search engine set by the user? > And who guarantees that, in the latter case, the ports 443 and 80 deliver the > same? It all seems to me like it would either be a gross hack (for DDG) or > something likely to break with other search engines or other use cases. I might > be missing something, of course. I was thinking we would just change the default gsettings value and the bookmarks, which doesn't seem like a hack and doesn't affect other search engines (after all, Epiphany only supports one search engine). What else were you thinking of doing? (In reply to comment #2) > I don't think this is a reasonable default. It could be the case that some > users are unable to access the port 443 because their ISP is blocking it or any > other reason. Do any ISPs actually do that? (Serious question.) That's downright evil. Even if a totalitarian country decides all your credit card numbers belong to eavesdroppers, do we really want to reduce security for everyone as a reaction? HTTPS Everywhere and HSTS would both be awesome to have, though.
*** Bug 709261 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > I don't think this is a reasonable default. It could be the case that some > users are unable to access the port 443 because their ISP is blocking it or any > other reason. I've tried simulating this kind of behavior with "iptables -A OUTPUT -p tcp --dport 443 -j REJECT" and the result for ddg is pretty much as expected: http://duckduckgo.com/ redirects to https://duckduckgo.com/ which does not load. So from a user perspective it doesn't work regardless whether it is http or https. The same happens for google as well. Only bing seems to still have a working http variant. So I think changing the bookmark and gsettings default would not be a hack and the right thing to do.
That is an issue on DDG side, I believe. They default to https (see the settings page).
Given that google is also redirecting to https by default and that most people access the internet through google searches the probability of such a provider existing seems rather small because blocking port 443 would mean blocking google. And even if such a provider exists it would probably require rather specific workarounds that could not be adressed with some default values in epiphany but rather require site specific configuration anyway. Sending search requests in clear text over the network on the other hand affects a much larger part of userbase. So I'd argue that it would be more sensible to optimize the default settings for that case. Also have you tried to contact the DDG people about them defaulting to https? Because if they are not going to change this, there would really be no point in using plain http.
Yup.... HTTPS by default is a security feature. Google, Facebook, EFF, and bugzilla.gnome.org do it. Wikipedia's planning to. It's a Good Thing.
Created attachment 256554 [details] [review] Use https rather than http for the default search Change the default bookmarks and gschema. Update ephy-web-view-test accordingly.
I'd appreciate a review of this patch. Either we default to HTTPS, or else we send our query in cleartext, my government (if not also others) intercepts and logs it, and then DDG upgrades us to HTTPS anyway. This seems like an easy choice to me. (Given that HSTS or HTTPS Everywhere would be better, this is a simple quick fix to protect users' searches.)
Review of attachment 256554 [details] [review]: Patch looks fine to me.
Updated slightly to account for changes in the tests and the preferences dialog. The following fix has been pushed: 4b80445 Use HTTPS for DDG and Google searches by default
Created attachment 265710 [details] [review] Use HTTPS for DDG and Google searches by default Change the default bookmarks, the gschema, and the search engine options in the preferences dialog
Review of attachment 265710 [details] [review]: Patch looks good from a technical point of view, indeed, but you didn't get a maintainer to agree with the arguments provided so far, so you shouldn't have pushed it. That being said I do believe it's worth trying this approach so let's just leave it in.
(In reply to comment #20) > Review of attachment 265710 [details] [review]: > > Patch looks good from a technical point of view, indeed, but you didn't get a > maintainer to agree with the arguments provided so far, so you shouldn't have > pushed it. Michael, as Claudio mentioned, the patch was in "reviewed" not "accepted" state. Bear this in mind in the future.
(In reply to comment #21) > Michael, as Claudio mentioned, the patch was in "reviewed" not "accepted" > state. Bear this in mind in the future. Understood, sorry about that!