2 ms·

On yeah I forgot to add to the list: * Apple breaking mac addresses for privacy * IPv6 privacy extensions (we can’t give everyone a stable address because tra

by dcow 5y ago

On yeah I forgot to add to the list: * Apple breaking mac addresses for privacy * IPv6 privacy extensions (we can’t give everyone a stable address because tracking). We have stable physical addresses… why is the answer to privacy problems “whelp I guess we cant have a nice global internet after-all? I will concede privacy extensions at least don’t clobber your ability to have a stable address since you still do. I’d just like to see user level control over which address to use for what instead of a blanket all browsing happens with your anonymous address. * Strong PKI/identity: cant give everyone client certs because they have a stable ID somebody might use to track you. IDK how about you give me an option when I connect to a site “do you want to connect as <handle> or connect anonymously”? These privacy violations really feel like a social problem that we’ve failed to wrangle so we reach for a technology solution at all costs.

vlovich123 5y ago
I’m not really sure what your point is. In the example, your ISP could monitor what sites you visit. With private relay no one gets to see the site you visit except you and the site. You established a relationship with your ISP to provide you with internet connectivity. Your ISP is trying to exploit that relationship to sell information about that internet connectivity to get additional revenue beyond that (not just for network optimization purposes which they don’t need the sites you visit). Conversely I establish a relationship with a random website to do whatever that is. Usually I haven’t consented to having them follow me around everywhere digitally or physically to unrelated sites. You can’t base it on trust because trust doesn’t scale to the size of the internet. * Configurable TLS - I’m pretty sure all non-mobile browsers and Android let you configure the trust chain if you want to MiTM yourself (if I recall correctly with Apple you have to jailbreak). That’s a bit more complicated since most will engage in certificate pinning but that was developed due to a specific type of security attack so I don’t know what the answer there is. MACs are randomized as part of the new wifi standard because people could literally follow you around physically from a distance (or even fully remotely). This isn’t an Apple thing. These aren’t hypothetical. These are defenses that are developed in response to active misbehavior on the part of parties unrelated between the two parties that are trying to establish a trusted relationship. Some times it’s fine without but the times when it’s not tends to be a bigger problem that’s exploited at scale.
- dcow 5y ago
  Re configurable TLS: TLS 1.3 allows services to perfectly pin certs and reject your custom root CA. It breaks the flow you are talking about that has worked up to 1.2. The answer is to not build a myopic protocol/technology that only cares about 1 dimension of usage. Re mac addresses: I’m not saying there aren’t valid reasons for people to want these changes. I’m asking the user be allowed to configure their privacy posture at the protocol level rather than assuming all users want i finite anonymity. Maybe you care about someone following your phone around in public but maybe at home you want to enable secure neighbor discovery and give your stationary devices strong link-level identity… My point is it’s complicated and “privacy at all costs” is not a one-size-fits-all silver bullet solution. I never argued these problems aren't real and only hypothetical. I’m asking to be given the ability at the protocol level to make informed decisions as to where I fall on the privacy vs security axis rather than be wholly subject to protocols that assume I always want maximum privacy.
  - Lukasa 5y ago
    > Re configurable TLS: TLS 1.3 allows services to perfectly pin certs and reject your custom root CA. It breaks the flow you are talking about that has worked up to 1.2. The answer is to not build a myopic protocol/technology that only cares about 1 dimension of usage. No it doesn't. I have no idea what technology you think this is (maybe HPKP?), but installing a local root CA absolutely continues to work in all browsers with TLS 1.3.
    - dcow 5y ago
      TLS proxies need to be able to inspect the server certificate response in order to dynamically generate an appropriate certificate. This flow doesn't work in TLS 1.3 since the certificate is encrypted to prevent MITM.
      - aisio 5y ago
        MITM for TLSv1.3 is possible. Plenty of solutions available for enterprises to do this. The MITM occurs still happens for TLSv1.3 on key exchange, allowing for the subsequent certificate to also be MITM and be replaced and encrypted. The only real affect TLSv1.3 has for MITM is that company policies for decryption can't match on the cert to determine if decrypt should occur, but they can still use the SNI which is plaintext

by dcow 5y ago

vlovich123 5y ago

I’m not really sure what your point is. In the example, your ISP could monitor what sites you visit. With private relay no one gets to see the site you visit except you and the site. You established a relationship with your ISP to provide you with internet connectivity. Your ISP is trying to exploit that relationship to sell information about that internet connectivity to get additional revenue beyond that (not just for network optimization purposes which they don’t need the sites you visit). Conversely I establish a relationship with a random website to do whatever that is. Usually I haven’t consented to having them follow me around everywhere digitally or physically to unrelated sites. You can’t base it on trust because trust doesn’t scale to the size of the internet. * Configurable TLS - I’m pretty sure all non-mobile browsers and Android let you configure the trust chain if you want to MiTM yourself (if I recall correctly with Apple you have to jailbreak). That’s a bit more complicated since most will engage in certificate pinning but that was developed due to a specific type of security attack so I don’t know what the answer there is. MACs are randomized as part of the new wifi standard because people could literally follow you around physically from a distance (or even fully remotely). This isn’t an Apple thing. These aren’t hypothetical. These are defenses that are developed in response to active misbehavior on the part of parties unrelated between the two parties that are trying to establish a trusted relationship. Some times it’s fine without but the times when it’s not tends to be a bigger problem that’s exploited at scale.

dcow 5y ago
Re configurable TLS: TLS 1.3 allows services to perfectly pin certs and reject your custom root CA. It breaks the flow you are talking about that has worked up to 1.2. The answer is to not build a myopic protocol/technology that only cares about 1 dimension of usage. Re mac addresses: I’m not saying there aren’t valid reasons for people to want these changes. I’m asking the user be allowed to configure their privacy posture at the protocol level rather than assuming all users want i finite anonymity. Maybe you care about someone following your phone around in public but maybe at home you want to enable secure neighbor discovery and give your stationary devices strong link-level identity… My point is it’s complicated and “privacy at all costs” is not a one-size-fits-all silver bullet solution. I never argued these problems aren't real and only hypothetical. I’m asking to be given the ability at the protocol level to make informed decisions as to where I fall on the privacy vs security axis rather than be wholly subject to protocols that assume I always want maximum privacy.
- Lukasa 5y ago
  > Re configurable TLS: TLS 1.3 allows services to perfectly pin certs and reject your custom root CA. It breaks the flow you are talking about that has worked up to 1.2. The answer is to not build a myopic protocol/technology that only cares about 1 dimension of usage. No it doesn't. I have no idea what technology you think this is (maybe HPKP?), but installing a local root CA absolutely continues to work in all browsers with TLS 1.3.
  - dcow 5y ago
    TLS proxies need to be able to inspect the server certificate response in order to dynamically generate an appropriate certificate. This flow doesn't work in TLS 1.3 since the certificate is encrypted to prevent MITM.
    - aisio 5y ago
      MITM for TLSv1.3 is possible. Plenty of solutions available for enterprises to do this. The MITM occurs still happens for TLSv1.3 on key exchange, allowing for the subsequent certificate to also be MITM and be replaced and encrypted. The only real affect TLSv1.3 has for MITM is that company policies for decryption can't match on the cert to determine if decrypt should occur, but they can still use the SNI which is plaintext