3 ms·

100% agree. If you want to ensure the integrity of content, then sign the content. If you want to protect people's interactions with websites when exchanging no

100% agree. If you want to ensure the integrity of content, then sign the content. If you want to protect people's interactions with websites when exchanging non-public data then use encryption when that's warranted. But credential-based encryption should never be used across sites or with public data because (as the poster notes) it just becomes another way in which broader interaction with the Internet can be tracked. It's trading yet more liberty for just a little bit more security, and haven't we all done enough of that already?

quonn 11y ago
> But credential-based encryption TLS does usually not use client-certificates, so it is not credential-based for the user.
Animats 11y ago
"100% agree. If you want to ensure the integrity of content, then sign the content." That's what "subresource integrity"[1] is about. For static data, a cryptographic hash of the linked content is attached to links. This detects any modifications of the document. Now you can use a CDN without trusting it. A big problem with "HTTPS Everywhere" is that it encourages termination of the secure connection at a CDN. The CDN can then tamper with the content. Some do, adding ads and trackers. Subresource integrity will detect such tampering, but HTTPS Everywhere will not. [1] http://www.w3.org/TR/SRI/ http://www.w3.org/TR/SRI/
- realityking 11y ago
  As the name implies, this only works for subresources (scripts, stylesheets, images, etc.) and is mainly useful for cross origin requests. HTTPS on the other hand also gurantees that the article I'm reading hasn't been modified. And that no one has injected ads into the site.
  - Animats 11y ago
    If you're using a CDN, you don't know if the CDN has injected ads or spyware. If you use Cloudflare's RocketLoader, what the user gets is not what you sent. Once a CDN is involved in "HTTPS Everywhere", it's security theater.
    - realityking 11y ago
      I (as the the website's owner) have to trust one more party, which I know and have a contract with. That's a whole lot better than having to trust any random third party between me and the user of my website.

quonn 11y ago

> But credential-based encryption TLS does usually not use client-certificates, so it is not credential-based for the user.

Animats 11y ago

"100% agree. If you want to ensure the integrity of content, then sign the content." That's what "subresource integrity"[1] is about. For static data, a cryptographic hash of the linked content is attached to links. This detects any modifications of the document. Now you can use a CDN without trusting it. A big problem with "HTTPS Everywhere" is that it encourages termination of the secure connection at a CDN. The CDN can then tamper with the content. Some do, adding ads and trackers. Subresource integrity will detect such tampering, but HTTPS Everywhere will not. [1] http://www.w3.org/TR/SRI/ http://www.w3.org/TR/SRI/

realityking 11y ago
As the name implies, this only works for subresources (scripts, stylesheets, images, etc.) and is mainly useful for cross origin requests. HTTPS on the other hand also gurantees that the article I'm reading hasn't been modified. And that no one has injected ads into the site.
- Animats 11y ago
  If you're using a CDN, you don't know if the CDN has injected ads or spyware. If you use Cloudflare's RocketLoader, what the user gets is not what you sent. Once a CDN is involved in "HTTPS Everywhere", it's security theater.
  - realityking 11y ago
    I (as the the website's owner) have to trust one more party, which I know and have a contract with. That's a whole lot better than having to trust any random third party between me and the user of my website.