searxng / searx-space

Statistics of the public SearX(NG) instances
https://searx.space/
GNU Affero General Public License v3.0
170 stars 27 forks source link

[Feature Request] SearX.Space: Add A "Eyes" Filter For Country #54

Open seniorm0ment opened 4 years ago

seniorm0ment commented 4 years ago

Eyes Filter

Would make browsing https://searx.space/ a lot easier by country, if there was an easy way to toggle only instances hosted outside of 5 eyes, 9 eyes, and 14 eyes. So I would suggest a basic dropdown near the country field, where you can just click 5, 9, or 14 eyes toggles, or select none to only see instances outside of the 14 eyes.

unixfox commented 4 years ago

No JS is tracked in #9.

dalf commented 4 years ago

Eyes Filter

It is no easy to deal with, because 5/9/14 eyes select only few countries : https://en.wikipedia.org/wiki/Internet_censorship_and_surveillance_by_country

Here, my wish is to allow the users to have persistent filters (*), including a multi-selection per country. The maintenance cost is zero.

A filter per censorship type will:

But if there is another project with an up to date list, searx-stats2 can use it (even in another language, most probably it is possible to import the data). Also, it is possible to create this project, but I don't have the time to make sure the list will be updated and accurate.

(*) [EDIT] there are different ways to make a persistent selection, do note most probably it will require javascript (with or without cookies).

Uptime Average

Yes. It is on the road map.

Extra: No JS

As @unixfox said, there are

seniorm0ment commented 4 years ago

9

Ah my bad, glad to see.

Eyes filter

It is no easy to deal with, because 5/9/14 eyes select only few countries : https://en.wikipedia.org/wiki/Internet_censorship_and_surveillance_by_country

I'm very confused at the issue here? I can't see why this would be hard to implement. 4 checkboxes, one for 5 eyes, one for 9 eyes, one for 14 eyes, one for all

If 5 eyes is selected, it only shows countries within 5 eyes. If 9 eyes is selected it shows countries within 9 eyes. If 14 eyes, it shows 14 eyes. If all is selected it shows all countries. If none or "outside 14 eyes" is selected it would show only servers hosted in countries outside of the 14 eyes. Or something along those lines.

At minimum, a simple toggle to simply see only servers hosted in countries outside the 14 eyes would be very nice imo.

I assume this would be pretty easy to aggregate, just take the list of countries, and just place them in their respective categories. It's not like it's dynamic content, countries don't change whether they're within the 14 eyes or not every hour :p

No?

dalf commented 4 years ago

Technically it is easy to implement.

I guess the purpose of the request is to escape the 5,9,14 eyes surveillance ?

5/9/14 eyes is one alliance, other countries have different types of surveillance, also I guess the surveillance programs evolve over time : as long the list is short and obvious it is easy to check for a mistake and/or old data.

Sooner or later, I expect someone else to ask add some other filters per country (few countries, a name, easy), but at the end we will have an unmaintained list that give a false sense of non surveillance. I prefer to not have a feature, rather than a "broken" feature. "broken" because by definition you can't see if it is broken except if you check carefully.

Even if we manage to the keep these country list up to date, most probably it is trickier than that (May be I'm wrong).

Scenario : an user connects from one location under surveillance to an searx instance free of surveillance, but the instance is badly configure. For example, the HTTPS server doesn't support perfect forward secrecy. Is it still okay ?

Another scenario: what if the user is under the same surveillance alliance than one of the engine : [user's IP under 5 eyes] ---> [ searx, free of surveillance ] --> [ engine under 5 eyes ] Is the surveillance program able to make the link (*) ? If yes, searx should also display which engines are under 5,9,14 eyes surveillance (I'm afraid it will be the case for most of the western engines).

(*) For now searx don't use HTTP/2, only HTTP/1 with keep alive. Is it easier to make the link between the in-going and out-going requests ?

Another scenario, what if the instance uses a proxy ? For now, you can't tell from searx.space if an instance is using a proxy (in the future, it can be reported as long the searx administrator doesn't work for the 5 eyes :-)

I'm not saying nothing should be done, but I would like to avoid to give a false sense of non surveillance.

According to what I know (I'm not an expert), the solution seems to be User -> Tor -> Searx -> ... .

seniorm0ment commented 4 years ago

Scenario : an user connects from one location under surveillance to an searx instance free of surveillance, but the instance is badly configure. For example, the HTTPS server doesn't support perfect forward secrecy. Is it still okay ?

Personally I'd argue the server configuration has absolutely nothing to do with this. This can happen on any instance, no matter where it is and I'd consider it an issue.

5/9/14 eyes is one alliance, other countries have different types of surveillance, also I guess the surveillance programs evolve over time : as long the list is short and obvious it is easy to check for a mistake and/or old data.

This is a very prominent alliance, and has been backed by facts for over a decade now, it will simply just make it easier to allow the user to select a server. Of course there will be surveillance programs all around the world unrelated and related to the eyes. I don't think this is a false sense of security/privacy, as this can essentially be said about everything. It should be utilized more as a guidance.

My biggest issue is just it is super hard to easily filter out countries one may not want to see, to see all the others and compare them. So maybe a filter to simply just hide specific countries, but this will need to manually be done every single time, and the user would need to essentially know the abbreviations for every place, as well as all 14 if they simply want to avoid one of the biggest if not biggest known alliance. Of course the non 14 eyes places can still do massive surveillance, almost all countries do. But there's a difference between collaboration and mass data sharing, and a country just doing surveillance on themselves. It's meant to be a guide, not a toggle that automatically shows means the non 14 eyes countries aren't surveilled servers. It simply pushes those results out, and makes it a bit easier to see and choose what you want. I mean again, I don't think it will be hard to maintain at all. It's not like this would be a list of countries that changes every hour. It's pretty much static.

Maybe a continent filter may be a better start though? I still don't see the harm in the 14 eyes filter personally.

Another scenario: what if the user is under the same surveillance alliance than one of the engine

I am a little confused as to what you are trying to suggest here. Again I think any server misconfigurations, proxies, and anything that has to do with where a user or server is should not be determined solely on whether or not the server is within the 14 eyes. But this is only meant as a guide and there are other factors that should be considered.

I don't disagree with giving users a false sense of surveillance, a disclaimer could be nice. But again, a guide is not a false sense of surveillance imo, it should still be up to the end users to make more informed decisions.


The other thing that came to my mind personally was maybe an average ip connection count. Of course this can be faked. I can't imagine there's any clean way to give a remotely accurate user count while respecting privacy. But a generalized ip connection report (maybe only optionally reported by the server, but still a field that can be provided) But it would maybe help give a generalized idea as to how active/popular a server is. Just another idea.

unixfox commented 3 years ago

I split the uptime feature into a new issue: https://github.com/searx/searx-stats2/issues/57 because this issue derived too for the Eyes Filter feature.