Software Criteria

[realguyman]

Currently we do not have any requirements that software recommendations must adhere to. I plan on fixing that by introducing criteria for software. This criteria would apply to all software, and no exceptions would be made.

First definitions must be proposed:

1. Software classifies as a Website when it is a web application (a composition of HTML, CSS, and JS or WebAssembly) served over a network to be used in a browser (NOTE: This includes PWAs).
2. Software classifies as a Native when it is an application which can be installed onto users devices (NOTE: This does NOT include PWAs).
3. Software classifies as a Server when it is optimized and primarily designed for relaying content to users through clients (such as Websites or Natives).

I propose:

1. Websites MUST be served over TLS v1.2 or newer.
2. Websites which claim E2EE is done on the client (i.e. through JS in the web application) MUST warn users of the dangers of E2EE on the web, MUST have Native equivalents, and SHOULD encourage equivalent Natives.
3. Software SHOULD utilize the current standard cryptography practices where applicable when cryptography is present, failure to do so could put the software on the back burner by the PrivacyGuides team.
4. Software which claims E2EE MUST do E2EE by default OOTB (out of the box) for non-public communication.

It should be pretty clear that the PrivacyGuides team needs to evaluate a lot of software, even with a software criteria in effect. As much as we want to keep this a fair and high quality process, I think everyone can agree we won't be able to make everyone happy about our recommendations or process.

A lot of people would probably like us to evaluate software based on Privacy Policies, or marketing, which isn't really our goal when we're evaluating based on the technical capabilities of the software. But they could be optional bonus points that don't equate to the actual evaluation (unless being compared to extremely similar software).

What is everyone's thoughts on this? What else should be required? Does the current proposed requirements make sense, or could they use improvements?

[jonaharagon]

This sounds good to me. Things I wonder:

Do all of our current recommendations fit these criteria?

You've established servers as a software category, but don't have any server-specific criteria. Something to brainstorm?

Software SHOULD utilize the current standard cryptography practices

Can we define this specifically somehow? Where do we draw the line between standards and homegrown stuff? Arguably Signal and Telegram both use their own homegrown cryptography, but Signal Protocol is significantly more respected for example.

Software which claims E2EE MUST do E2EE by default

Does this mean all software that implements E2EE communications, or only software that strongly advertises it? I might change this to "software which supports E2EE must do E2EE by default."

Websites which claim E2EE is done on the client (i.e. through JS in the web application) MUST warn users of the dangers of E2EE on the web

Do many websites which use E2EE currently do this? ProtonMail and Element both come to mind as websites that don't, as far as I'm aware.

[realguyman]

You've established servers as a software category, but don't have any server-specific criteria. Something to brainstorm?

Yes.

Can we define this specifically somehow? Where do we draw the line between standards and homegrown stuff? Arguably Signal and Telegram both use their own homegrown cryptography, but Signal Protocol is significantly more respected for example.

Standardized cryptographic primitives would be cryptographic primitives that have been widely accepted by the community as secure. Such as (X)Salsa20(/12)(-Poly1305), (X)ChaCha20(/12)(-Poly1305), AES-GCM, AES-CTR, AES-CBC, ..., Argon2(i)(d), Scrypt, PBKDF2, ..., BLAKE2, SHA2, SHA3, ..., Curve25519, Ed25519, X25519, etc.

Using standardized cryptographic primitives that are considered secure is the absolute bare minimum effort. But it's a good place to put requirements.

Does this mean all software that implements E2EE communications, or only software that strongly advertises it? I might change this to "software which supports E2EE must do E2EE by default."

Software that implements E2EE. So yes, it should be claim "supports".

Do many websites which use E2EE currently do this? ProtonMail and Element both come to mind as websites that don't, as far as I'm aware.

The warning might be unpractical as all of the recommendations don't warn users. We could simply put a warning on our site for recommendations and point to a link explaining why E2EE on the web is flawed.

[jonaharagon]

We could simply put a warning on our site for recommendations and point to a link explaining why E2EE on the web is flawed.

This is my preferred solution. An overview article on E2EE in general that includes this information would probably be the best way to go abut this.