💬 Discussion | Australia data encryption law #650

New Issue

2018-12-07T15:34:24Z

ThatLurker commented

2018-12-07 15:34:24 +00:00

(Migrated from github.com)

We might soon need a "please don't use services that are in Australia" warning.

One info source for this: https://www.eff.org/deeplinks/2018/09/australian-government-ignores-experts-advancing-its-anti-encryption-bill

We might soon need a "please don't use services that are in Australia" warning. One info source for this: https://www.eff.org/deeplinks/2018/09/australian-government-ignores-experts-advancing-its-anti-encryption-bill

👍 1

Atavic commented

2018-12-08 00:07:23 +00:00

(Migrated from github.com)

please don't use services that are in Australia

The australian bill may only make clear something they potentially can already do.

Issue related to https://github.com/privacytoolsIO/privacytools.io/issues/431

> please don't use services that are in Australia The australian bill may only make clear something they potentially can already do. Issue related to https://github.com/privacytoolsIO/privacytools.io/issues/431

ghost commented

2019-01-17 03:44:36 +00:00

(Migrated from github.com)

Something you may find of interest regarding this - https://source.netsyms.com/Netsyms/AusBlock

privacytoolsIO commented

2019-04-02 04:06:11 +00:00

(Migrated from github.com)

How about "Don't use services that are within FiveEyes (USA, UK, AUS, NZ, CAN)"

Would that make sense at this point?

How about "Don't use services that are within FiveEyes (USA, UK, AUS, NZ, CAN)" Would that make sense at this point?

Mikaela commented

2019-04-02 07:58:51 +00:00

(Migrated from github.com)

I am not sure, because countries outside of Five Eyes aren't perfect either. Sweden (seems to be number 14 of Fourteen Eyes in PrivacyTools.io) is surveilling all traffic going through them since a long time ago, and Finland is going to start surveilling all traffic going across borders (even if as far as I am aware there won't be a permission to attempt decrypting traffic).

ThatLurker commented

2019-04-11 11:47:14 +00:00

(Migrated from github.com)

How about something like "Try to use services that are within these countries (list of countries here)"

five-c-d commented

2019-04-11 19:28:02 +00:00

(Migrated from github.com)

Don't use services that are within FiveEyes

There are four main ways to be "within" the surveillance of the FiveEyes nations

servers (for download and/or for operations) are hosted within FiveEyes borders
people responsible (for the downloadable-binaries and the server-nodes) are subject to the FiveEyes governments
international agreements such as FourteenEyes, or traditions of cooperation such as Switzerland is alleged to have
international disagreements, aka the traditional risk of spying "illegally"

Depending on the type of privacy-tool, applying such rules can get tricky quickly.

example: the VPN category, analysis of 5+2 providers

In the VPN category, Mullvad is in Sweden, so it is 14-eyes and thus as risk of attack#3 ... but mullvad is only partially at risk of attack#1, unless you specifically connect to a node of the mullvad network which is located in Australia or the USA or something. So far as I know mullvad is immune from type#2 risks because the owners are not subject to FiveEyes jurisdiction. Sweden is probably spied upon by other nations, e.g. China/Iran/whatever, because it is in the EU, but I do not know how to quantify the risk#4 very well because I don't have much idea about how juicy of a target Swedish industry&infrastructure is, to foreign governments.

PIA of USA (not listed) is subject to risk#1, risk#2, and risk#3-by-way-of-risk#1 with all the 14eyes countries, but is pretty resistant to risk#4 because declaring cyberwar on the USA is somewhat dangerous -- only major powers like China and Russia might take such risks. There are thousands of PIA server-nodes though, spread all over the place, and with a huge attack-surface like that at any given time some nodes will be pwn'd ... so there definitely is some risk#4 but it is hard to say how much.

TunnelBear is canadian (not listed) but owned by McAfee of USA, subject to risk#1 and risk#2 as well as risk#3-by-way-of-risk#1, and less resistant to risk#4 than PIA despite the smaller attack-surface, because of the freemium-nature of TunnelBear (they have to retain bandwidth-usage-logfile metadata which means there server-nodes ARE setup to record such things unlike the best no-logs-policy VPNs are presumably configured).

iVPN is an interesting case, it is in Gibraltar and thus theoretically not subject to risk#1, but the owners are UK citizens and thus risk#2 is definitely present. Unclear how much cooperation the independent-but-tiny state of Gibraltar would offer, in a risk#3 type of situation. Seems unlikely that Gibraltar has many international enemies, since they are defended by the UK and thus by NATO... but although that tends to make risk#4 low, it would make risk#3 higher in some sense.

ProtonVPN is a borderline-situation, they have servers in Switzerland and Iceland plus also in Sweden when it comes to their SecureCore paying customers can access... that makes them better-off than Mullvad when it comes to risk#3, and they are mostly-immune to risk#2 and risk#1. Unclear whether protonVPN is immune to risk#4 but I suspect not, and I do not believe protonVPN is immune to risk#3 either because Switzerland and Sweden and to a lesser degree Iceland are pretty cooperative with FiveEyes/FourteenEyes despite their strong privacy-laws. None of this applies to the freemium-version of protonVPN because those endusers do not get SecureCore as a feature.

Providers like Trust.Zone that are located in the Seychelles tend to be immune from risk#1, but to say whether they are immune from risk#2 we have to know who runs/owns them (what country they reside in), and I don't know those answers. Risk#3 is very low with tax-havens, but risk#4 is very high: Seychelles has no military to speak of, no major allies that would raise a stink, and thus plenty of adversaries might be willing to use attack#4 type things to pwn the servers in Seychelles because there would be little backlash.

NordVPN is technical-on-paper HQ'd in Panama which helps lessen risk#1, and has thousands of servers all over the world which tends to also lessen some localized risks (you can pick any node to connect unto and any as your exit-node which helps in certain threat-models). But my understanding is the "nord" comes from the owners living in the nordic countries, which are 14eyes jurisdiction, and thus risk#2 is higher. Risk#3 is low, except to the extent it is the same as risk#2 methinks. Risk#4 is presumably very high, Panama is a target that can be used as a convenient excuse to infiltrate drug cartels or tax-avoidance infrastructure or whatever, and the sheer number of server-nodes means the attack-surface worldwide is also severe. There are also some trackers in the default NordVPN client APK... although it is possible to avoid those trackers by using a non-default client, that they exist at all, tends to be worrisome. Obviously not a jurisdictional question, just throwing that in here to remind folks that jurisdiction is not the main question. The main question is, Do You Trust This Vpn Service, because if they CANNOT truly be trusted it does not matter where they are domiciled nor where their employees happen to be citizenry of.

example: the VoIP+IM categories, analysis of 6 tools

signalapp is first-listed in voip and first-listed in im, but it is based in the USA and runs on AWS nodes (Amazon also based in the USA) and has a policy that all Signal Foundation employees are USA residents. This makes risk#1 and risk#2 both seem excruciatingly high... but I would argue that signalapp is a special case, because they are so pugnaciously anti-NSA, with Snowden on the homepage at signal.org and so on... there is a PR worry, if some agency of the USA government were caught spying on signal-servers, or coercing signal-foundation employees, or anything along those lines. Risk#3 is similar, but distinct: signalapp is in a fiveEyes country, and the new laws in Australia, plus the previously-existing ones in the UK, are very worrisome. Major governments are comfy surveilling their own citizenry "indirectly" ... an agency in nation X makes a deal with a cooperative agency in nation Y to spy on the citizenry of X... and then covertly feed the results back to the agency within nation X, who then has plausible deniability. Risk#4 is relatively low for signalapp, methinks... being in the USA, and all employees as residents (and usually citizens methinks) has the advantage that hostile espionage acts would potentially blow up into a PR nightmare for the adverary-nation, if they were caught... and this will deter many (but not all) kinds of adversaries from attempting attack#4. Unlike PIA there are a fairly small number of signal-server nodes worldwide, dozens methinks rather than thousands, which helps.

Wireapp is mostly-safe from risk#1 since they are Switzerland-and-EU-based servers, but definitely subject to risk#2 because they are HQ'd in the USA like signalapp (and unlike signalapp are not as well-known in the press coverage that a breach would generate were the adversary caught in the act). Risk#3 is reasonably high for wireapp, because unlike protonVPN my understanding is that the wireapp servers in switzerland are AWS-hosted, and some combination of pressure on Amazon plus tendency to cooperate by Swiss authorities plus wireapp HQ being in the USA makes it seem plausible that intergovernmental cooperation could lead to a server-node breach at some point. And because wireapp keeps all metadata server-side, for the lifetime of every user-identity, even one breach lasting one hour would be catastrophic to the wireapp-network. (Thanks to SGX enclaves breach of a signal-server node illegally would need a much longer timespan to capture metadata ... timing-analysis is possible, but takes a fairly long baseline-timespan, probably measured in weeks rather than in minutes.) Analyzing risk#4 with wireapp is tricky because of all the places they are connected unto... HQ in USA, plus AWS server-nodes in Switzerland and other unspecified EU countries... but because of the server-side metadata, an adversary might be willing to take such a risk. They need only infiltrate any given wireapp-server, and then exfiltrate whatever metadata they were after in the course of an hour (or five minutes if this is a surgical operation aiming at specific users only), and then get out and erase their tracks... or plant false tracks to make it look like Somebody Else was responsible for the breach-attempt. The metadata stored server-side makes these juicy targets, even for non-fourteen-eyes adversaries, methinks.

RiotIM has two deployment-options, RiotIM+Synapse where the enduser or someone they trust is running a homeserver, and RiotIM alone which connects to the main MatrixOrg infrastructure. The latter situation is less hassle, but problematic in the same way as wireapp because gobs of metadata are stored server-side. There are a LOT of servers so there is also a large attack-surface, and brief smash&grab pwn'ing is enough to exfiltrate a lot of metadata about specific targets in a surgical cracking-operation. Running your own homeserver, or having somebody you trust run a homeserver for The Group, is a reasonable way to workaround many issues, in particular jurisdictional ones: you can pick exactly where the synapse-server is hosted/located to avoid risk#1 jurisdictional issues, you can pick exactly who has sysadmin access to that server (and what their residency/citizenship status is) to avoid risk#2 jurisdictional issues, and so on. To some degree you can also avoid risk#3 type issues. The main downside is risk#4 type of things... the further away you are from cooperative jurisdictions, the more likely risk#4 becomes when you are running a self-hosted synapse homeserver. If the system stands out, that is, and becomes a target. It might not: if you and your group are keeping your noses clean, never doing any illicit let alone illegal via your server, and not connected to anyone doing anything like that either, your machine might well never become a surveillance-target in the first place. But it is hard to not stand out, when you are going to significant lengths like this: running your own 'weird' chat program, not using the normal chat-servers but setting up your own, not using a typical hosting-provider but hunting up a wildcat provider, going to great lengths to harden the security of the bastion-host, and so on and so on.

The various XMPP-OMEMO things are similar to RiotIM, but unlike running your own Synapse server and flipping on MegOlm, or connecting to a public room and flipping on MegOlm, running your own encrypted XMPP session is going to stand out considerably more. You have to get everybody using clients which support OMEMO, and which play nicely with each other. You have to contact a server which allows OMEMO (ejabberd disables it by default if memory serves still). And then, if you want to avoid leaking server-side metadata to untrusted third party server-operators, you have to setup your own prosody or ejabberd, configure it for OMEMO, get all the group using it, harden it, and so on. Because the government of France is using MatrixOrg nowadays, and because MegOlm is off-by-default but built into most of the client-apps, it is signifcantly easier to Not Stand Out with your own e2e crypto Synapse homeserver, than it is with your own ejabberd OMEMO system. I don't have quantitative info on exactly how significant, though, this is mostly handwaving rather than hard numbers of userbase + percentage with crypto enabled + percentage self-hosting and so on.

Jami is primarily implemented by a Canadian linux-consulting firm, so in some sense the providers of Jami are in five-eyes jurisdiction, but because it is a server-less decentralized protocol, and most endusers get Jami via F-Droid and their reproducible-build infrastructure, the vast majority of risk#1 simply evaporates, as does the large majority of risk#2. It would still be plausible for a 5eyes nation to pressure the Jami developers personally, get them to upload a bad binary to the playStore ... but thanks to the reproducible builds at F-Droid, endusers on THAT release-channel would be largely secure against such an attack-vector. Risk#3 is very low, for the same reasons that risk#2 and risk#1 are very low. Risk#4 is heightened by comparison to the other risks -- I can imagine a scenario where the Chinese would bring on a cracker-group to pwn the build-servers of F-Droid if there were millions of dissidents within China using Jami for instance -- but risk#4 is still low, and especially when compared to the overall risk of the non-federated alternatives like wireapp and signalapp. From a jurisdictional point of view, therefore, Jami is definitely the winner...

Tox is arguably better than Jami in some ways, and like Jami gains a lot of advantages over most alternatives thanks to decentralization. But, UNLIKE jami which is a wholesomely-named calling-app designing by friendly Canadians, methinks risk#4 with Tox is quite high -- just installing something named after toxic waste is probably Standing Out with a big bold neon sign saying "here is somebody interesting."

I don't know enough about Linphone and Jitsi and RetroShare to analyze them yet.

In summary, everything is terrible :-)

Would that [delisting all 5eyes tools] make sense at this point?

It depends partly on the threat-model of the enduser/readership... are they worried about cops and the NSA, type of surveillance, or are they more worried about organized crimelords/cartels, cracker gangs out to commit identity theft, maybe some kind of localized need for privacy against industrial competitors or nosy neighbors or whatever.

list of 5eyes-based apps&providers

If you eliminate any USA-based servers, you have to drop firefox and signalapp, plus might have to drop a large number of the VPN providers (almost all of them have exit-nodes in the USA somewhere) depending on what the rules-for-dropping end up being. If you eliminate any USA-HQ'd providers, you drop wireapp as well, and possibly jami depending on whether you count the 'provider' of Jami as the F-Droid people which are outside the 5eyes or the Savoir-Faire Linux firm which is in Canada.

No question this decision, if taken to the hilt (where any entity with some taint of 5eyes, however faint, was ruthlessly cut from being mentioned), would fundamentally alter than nature of the privacyToolsIO listings overall. No longer would it be a list the average everyday enduser could skim through, and say "these are probably ideal". It would instead be concentrating on extremely-privacy-conscious endusers that were wanting to maximize their personal privacy-levels, and willing to cut off contact with anybody NOT also willing to maximize privacy. And maybe that is the goal for privacyToolsIO, to cater to privacy-nerds and help them communicate with each other. But if the goal is to help the everyday masses incrementally boost their privacy-levels, then this kind of taint-free-or-get-removed approach is a mistake, methinks.

My suggestion is that the connected-to-5eyes kinds of information should be highlighted, ideally using the wizard-level idea to graphically indicate "how private" each app is, in various respects. If that happens, it might make sense to list TunnelBear (canada) and PIA (usa) into the vpn-list for the first time, and Hushmail (canada) into the email-list perhaps, which at present is the only two subsections which elide 5eyes-based providers. Or, since there ARE so many quality options amongst vpn & webmail providers who are NOT based in 5eyes countries, the VPN listings could stay like they are.

But in most other categories outside the vpn&webmail listings, if you get rid of the USA-or-UK-based offerings you cut out good options: Firefox/Thunderbird, Signalapp, maybe Wireapp (per risk#2), DuckDuckGo possibly Friendica (non-corporate but devs collaborate via USA-owned github), conceivably OpenNIC (per risk#2 and possibly via risk#1 if they formed a nonprofit entity), Puppy Linux of Australia (Kauler has largely passed the torch but the new torchbearers are also Aussies methinks), possibly Ubuntu Touch depending on how you slice the "location" of whatever they are nowadays. Might be others, I don't know all the tools on the privacyToolsIO listings -- part of the reason I like it, not just the basics are covered.

(Edit: today I learned, although they have a French subsidiary now in 9eyes territory, officially the MatrixOrg developers are HQ'd in London which is 5eyes territory, which puts them in a similar position to wireapp and their USA HQ but Swiss-domiciled AWS servers.)

By any stretch of the word, it would distinctly skew the lists to have firefox and signalapp and that other stuff delisted. Whether the skew would be "finally making privacyToolsIO achieve the vision it was striving for all this time" or instead would be "oh nohz now privacyToolsIO is less useful/pragmatic/utilitarian" ... well, that call is not up to me, that is a matter of interpretation. What is the intended audience of the listings? Hardcore privacy-conscious folks, or the everyday enduser wanting to get a bit more privacy with there-is-an-app-for-that listings?

> Don't use services that are within FiveEyes There are four main ways to be "within" the surveillance of the FiveEyes nations 1. servers (for download and/or for operations) are hosted within FiveEyes borders 2. people responsible (for the downloadable-binaries and the server-nodes) are subject to the FiveEyes governments 3. international agreements such as FourteenEyes, or traditions of cooperation such as Switzerland is alleged to have 4. international *dis*agreements, aka the traditional risk of spying "illegally" Depending on the type of privacy-tool, applying such rules can get tricky quickly. <details><summary>example: the VPN category, analysis of 5+2 providers</summary> In the VPN category, Mullvad is in Sweden, so it is 14-eyes and thus as risk of attack#3 ... but mullvad is only partially at risk of attack#1, unless you specifically connect to a node of the mullvad network which *is* located in Australia or the USA or something. So far as I know mullvad is immune from type#2 risks because the owners are not subject to FiveEyes jurisdiction. Sweden is probably spied upon by other nations, e.g. China/Iran/whatever, because it is in the EU, but I do not know how to quantify the risk#4 very well because I don't have much idea about how juicy of a target Swedish industry&infrastructure is, to foreign governments. PIA of USA (not listed) is subject to risk#1, risk#2, and risk#3-by-way-of-risk#1 with all the 14eyes countries, but is pretty resistant to risk#4 because declaring cyberwar on the USA is somewhat dangerous -- only major powers like China and Russia might take such risks. There are thousands of PIA server-nodes though, spread all over the place, and with a huge attack-surface like that at any given time *some* nodes will be pwn'd ... so there definitely *is* some risk#4 but it is hard to say how much. TunnelBear is canadian (not listed) but owned by McAfee of USA, subject to risk#1 and risk#2 as well as risk#3-by-way-of-risk#1, and less resistant to risk#4 than PIA despite the smaller attack-surface, because of the freemium-nature of TunnelBear (they have to retain bandwidth-usage-logfile metadata which means there server-nodes ARE setup to record such things unlike the best no-logs-policy VPNs are presumably configured). iVPN is an interesting case, it is in Gibraltar and thus theoretically not subject to risk#1, but the owners are UK citizens and thus risk#2 is definitely present. Unclear how much cooperation the independent-but-tiny state of Gibraltar would offer, in a risk#3 type of situation. Seems unlikely that Gibraltar has many international enemies, since they are defended by the UK and thus by NATO... but although that tends to make risk#4 low, it would make risk#3 higher in some sense. ProtonVPN is a borderline-situation, they have servers in Switzerland and Iceland plus also in Sweden when it comes to their SecureCore paying customers can access... that makes them better-off than Mullvad when it comes to risk#3, and they are mostly-immune to risk#2 and risk#1. Unclear whether protonVPN is immune to risk#4 but I suspect not, and I do not believe protonVPN is immune to risk#3 either because Switzerland and Sweden and to a lesser degree Iceland are pretty cooperative with FiveEyes/FourteenEyes despite their strong privacy-laws. None of this applies to the freemium-version of protonVPN because those endusers do not get SecureCore as a feature. Providers like Trust.Zone that are located in the Seychelles tend to be immune from risk#1, but to say whether they are immune from risk#2 we have to know who runs/owns them (what country they reside in), and I don't know those answers. Risk#3 is very low with tax-havens, but risk#4 is very high: Seychelles has no military to speak of, no major allies that would raise a stink, and thus plenty of adversaries might be willing to use attack#4 type things to pwn the servers in Seychelles because there would be little backlash. NordVPN is technical-on-paper HQ'd in Panama which helps lessen risk#1, and has thousands of servers all over the world which tends to also lessen some localized risks (you can pick any node to connect unto and any as your exit-node which helps in certain threat-models). But my understanding is the "nord" comes from the owners living in the nordic countries, which are 14eyes jurisdiction, and thus risk#2 is higher. Risk#3 is low, except to the extent it is the same as risk#2 methinks. Risk#4 is presumably very high, Panama is a target that can be used as a convenient excuse to infiltrate drug cartels or tax-avoidance infrastructure or whatever, and the sheer number of server-nodes means the attack-surface worldwide is also severe. There are also some trackers in the default NordVPN client APK... although it is possible to avoid those trackers by using a non-default client, that they exist at all, tends to be worrisome. Obviously not a jurisdictional question, just throwing that in here to remind folks that jurisdiction is not the *main* question. The main question is, Do You Trust This Vpn Service, because if they CANNOT truly be trusted it does not matter where they are domiciled nor where their employees happen to be citizenry of. </details> <details><summary>example: the VoIP+IM categories, analysis of 6 tools</summary> signalapp is first-listed in voip and first-listed in im, but it is based in the USA and runs on AWS nodes (Amazon also based in the USA) and has a policy that all Signal Foundation employees are USA residents. This makes risk#1 and risk#2 both seem excruciatingly high... but I would argue that signalapp is a special case, because they are so pugnaciously anti-NSA, with Snowden on the homepage at signal.org and so on... there is a PR worry, if some agency of the USA government were caught spying on signal-servers, or coercing signal-foundation employees, or anything along those lines. Risk#3 is similar, but distinct: signalapp is in a fiveEyes country, and the new laws in Australia, plus the previously-existing ones in the UK, are very worrisome. Major governments are comfy surveilling their own citizenry "indirectly" ... an agency in nation X makes a deal with a cooperative agency in nation Y to spy on the citizenry of X... and then covertly feed the results back to the agency within nation X, who then has plausible deniability. Risk#4 is relatively low for signalapp, methinks... being in the USA, and all employees as residents (and usually citizens methinks) has the advantage that hostile espionage acts would potentially blow up into a PR nightmare for the adverary-nation, if they were caught... and this will deter many (but not all) kinds of adversaries from attempting attack#4. Unlike PIA there are a fairly small number of signal-server nodes worldwide, dozens methinks rather than thousands, which helps. Wireapp is mostly-safe from risk#1 since they are Switzerland-and-EU-based servers, but definitely subject to risk#2 because they are HQ'd in the USA like signalapp (and unlike signalapp are not as well-known in the press coverage that a breach would generate were the adversary caught in the act). Risk#3 is reasonably high for wireapp, because unlike protonVPN my understanding is that the wireapp servers in switzerland are AWS-hosted, and some combination of pressure on Amazon plus tendency to cooperate by Swiss authorities plus wireapp HQ being in the USA makes it seem plausible that intergovernmental cooperation could lead to a server-node breach at some point. And because wireapp keeps all metadata server-side, for the lifetime of every user-identity, even one breach lasting one hour would be catastrophic to the wireapp-network. (Thanks to SGX enclaves breach of a signal-server node illegally would need a much longer timespan to capture metadata ... timing-analysis is possible, but takes a fairly long baseline-timespan, probably measured in weeks rather than in minutes.) Analyzing risk#4 with wireapp is tricky because of all the places they are connected unto... HQ in USA, plus AWS server-nodes in Switzerland and other unspecified EU countries... but because of the server-side metadata, an adversary might be willing to take such a risk. They need only infiltrate any given wireapp-server, and then exfiltrate whatever metadata they were after in the course of an hour (or five minutes if this is a surgical operation aiming at specific users only), and then get out and erase their tracks... or plant false tracks to make it look like Somebody Else was responsible for the breach-attempt. The metadata stored server-side makes these juicy targets, even for non-fourteen-eyes adversaries, methinks. RiotIM has two deployment-options, RiotIM+Synapse where the enduser or someone they trust is running a homeserver, and RiotIM alone which connects to the main MatrixOrg infrastructure. The latter situation is less hassle, but problematic in the same way as wireapp because gobs of metadata are stored server-side. There are a LOT of servers so there is also a large attack-surface, and brief smash&grab pwn'ing is enough to exfiltrate a lot of metadata about specific targets in a surgical cracking-operation. Running your own homeserver, or having somebody you trust run a homeserver for The Group, is a reasonable way to workaround many issues, in particular jurisdictional ones: you can pick exactly where the synapse-server is hosted/located to avoid risk#1 jurisdictional issues, you can pick exactly who has sysadmin access to that server (and what their residency/citizenship status is) to avoid risk#2 jurisdictional issues, and so on. To some degree you can also avoid risk#3 type issues. The main downside is risk#4 type of things... the further away you are from cooperative jurisdictions, the more likely risk#4 becomes when you are running a self-hosted synapse homeserver. **If** the system stands out, that is, and becomes a target. It might not: if you and your group are keeping your noses clean, never doing any illicit let alone illegal via your server, and not connected to anyone doing anything like that either, your machine might well never become a surveillance-target in the first place. But it is hard to not stand out, when you are going to significant lengths like this: running your own 'weird' chat program, not using the normal chat-servers but setting up your own, not using a typical hosting-provider but hunting up a wildcat provider, going to great lengths to harden the security of the bastion-host, and so on and so on. The various XMPP-OMEMO things are similar to RiotIM, but unlike running your own Synapse server and flipping on MegOlm, or connecting to a public room and flipping on MegOlm, running your own encrypted XMPP session is going to stand out considerably more. You have to get everybody using clients which support OMEMO, and which play nicely with each other. You have to contact a server which allows OMEMO (ejabberd disables it by default if memory serves still). And then, if you want to avoid leaking server-side metadata to untrusted third party server-operators, you have to setup your own prosody or ejabberd, configure it for OMEMO, get all the group using it, harden it, and so on. Because the government of France is using MatrixOrg nowadays, and because MegOlm is off-by-default but built into most of the client-apps, it is signifcantly easier to Not Stand Out with your own e2e crypto Synapse homeserver, than it is with your own ejabberd OMEMO system. I don't have quantitative info on *exactly* how significant, though, this is mostly handwaving rather than hard numbers of userbase + percentage with crypto enabled + percentage self-hosting and so on. Jami is primarily implemented by a Canadian linux-consulting firm, so in some sense the providers of Jami are in five-eyes jurisdiction, but because it is a server-less decentralized protocol, and most endusers get Jami via F-Droid and their reproducible-build infrastructure, the vast majority of risk#1 simply evaporates, as does the large majority of risk#2. It would still be plausible for a 5eyes nation to pressure the Jami developers personally, get them to upload a bad binary to the playStore ... but thanks to the reproducible builds at F-Droid, endusers on THAT release-channel would be largely secure against such an attack-vector. Risk#3 is very low, for the same reasons that risk#2 and risk#1 are very low. Risk#4 is heightened by comparison to the other risks -- I can imagine a scenario where the Chinese would bring on a cracker-group to pwn the build-servers of F-Droid if there were millions of dissidents within China using Jami for instance -- but risk#4 is still low, and especially when compared to the overall risk of the non-federated alternatives like wireapp and signalapp. From a jurisdictional point of view, therefore, Jami is definitely the winner... Tox is arguably better than Jami in some ways, and like Jami gains a lot of advantages over most alternatives thanks to decentralization. But, UNLIKE jami which is a wholesomely-named calling-app designing by friendly Canadians, methinks risk#4 with Tox is **quite** high -- just installing something named after toxic waste is probably Standing Out with a big bold neon sign saying "here is somebody interesting." I don't know enough about Linphone and Jitsi and RetroShare to analyze them yet. </details> In summary, everything is terrible :-) > Would that [delisting all 5eyes tools] make sense at this point? It depends partly on the threat-model of the enduser/readership... are they worried about cops and the NSA, type of surveillance, or are they more worried about organized crimelords/cartels, cracker gangs out to commit identity theft, maybe some kind of localized need for privacy against industrial competitors or nosy neighbors or whatever. <details><summary>list of 5eyes-based apps&providers</summary> If you eliminate any USA-based servers, you have to drop firefox and signalapp, plus might have to drop a large number of the VPN providers (almost all of them have exit-nodes in the USA somewhere) depending on what the rules-for-dropping end up being. If you eliminate any USA-HQ'd providers, you drop wireapp as well, and possibly jami depending on whether you count the 'provider' of Jami as the F-Droid people which are outside the 5eyes or the Savoir-Faire Linux firm which is in Canada. No question this decision, if taken to the hilt (where any entity with some taint of 5eyes, however faint, was ruthlessly cut from being mentioned), would fundamentally alter than nature of the privacyToolsIO listings overall. No longer would it be a list the average everyday enduser could skim through, and say "these are probably ideal". It would instead be concentrating on extremely-privacy-conscious endusers that were wanting to maximize their personal privacy-levels, and willing to cut off contact with anybody NOT also willing to maximize privacy. And maybe that is the *goal* for privacyToolsIO, to cater to privacy-nerds and help them communicate with each other. But if the goal is to help the everyday masses incrementally boost their privacy-levels, then this kind of taint-free-or-get-removed approach is a mistake, methinks. My suggestion is that the connected-to-5eyes kinds of information should be highlighted, ideally using the wizard-level idea to graphically indicate "how private" each app is, in various respects. If that happens, it might make sense to list TunnelBear (canada) and PIA (usa) into the vpn-list for the first time, and Hushmail (canada) into the email-list perhaps, which at present is the only two subsections which elide 5eyes-based providers. Or, since there ARE so many quality options amongst vpn & webmail providers who are NOT based in 5eyes countries, the VPN listings could stay like they are. But in most other categories outside the vpn&webmail listings, if you get rid of the USA-or-UK-based offerings you cut out good options: Firefox/Thunderbird, Signalapp, maybe Wireapp (per risk#2), DuckDuckGo possibly Friendica (non-corporate but devs collaborate via USA-owned github), conceivably OpenNIC (per risk#2 and possibly via risk#1 if they formed a nonprofit entity), Puppy Linux of Australia (Kauler has largely passed the torch but the new torchbearers are also Aussies methinks), possibly Ubuntu Touch depending on how you slice the "location" of whatever they are nowadays. Might be others, I don't know all the tools on the privacyToolsIO listings -- part of the reason I like it, *not* just the basics are covered. (Edit: today I learned, although they have a French subsidiary now in 9eyes territory, officially the MatrixOrg developers are HQ'd in London which is 5eyes territory, which puts them in a similar position to wireapp and their USA HQ but Swiss-domiciled AWS servers.) </details> By any stretch of the word, it *would* distinctly skew the lists to have firefox and signalapp and that other stuff delisted. Whether the skew would be "finally making privacyToolsIO achieve the vision it was striving for all this time" or instead would be "oh nohz now privacyToolsIO is less useful/pragmatic/utilitarian" ... well, that call is not up to me, that is a matter of interpretation. What is the intended audience of the listings? Hardcore privacy-conscious folks, or the everyday enduser wanting to get a bit more privacy with there-is-an-app-for-that listings?

blacklight447 commented

2019-08-09 19:55:50 +00:00

(Migrated from github.com)

any updates on this?

Atavic commented

2019-08-22 19:26:23 +00:00

(Migrated from github.com)

Australia's anti-encryption laws being used to bypass journalist protections, expert says.
From: theguardian

Australia's anti-encryption laws being used to bypass journalist protections, expert says. From: theguardian

Mikaela commented

2019-08-22 21:26:57 +00:00

(Migrated from github.com)

Link?

ThatLurker commented

2019-08-23 10:34:26 +00:00

(Migrated from github.com)

@Mikaela https://www.theguardian.com/australia-news/2019/jul/08/australias-anti-encryption-laws-being-used-to-bypass-journalist-protections-expert-says

👍 1

dngray commented

2020-03-26 17:14:45 +00:00

(Migrated from github.com)

Australia was never a good place to host things. Closing as this will be resolved by https://github.com/privacytoolsIO/privacytools.io/issues/1437

Discussions really should take place on the forums or Reddit. Github issues are regarding changes to the site.

Australia was never a good place to host things. Closing as this will be resolved by https://github.com/privacytoolsIO/privacytools.io/issues/1437 Discussions really should take place on the forums or Reddit. Github issues are regarding changes to the site.

This repo is archived. You cannot comment on issues.