4 ms·

I'm surprised that nobody is concerned that Google (or whoever) is spamming the Internet to make everyone do what Google / TLS devs want them to do. First, it'

I'm surprised that nobody is concerned that Google (or whoever) is spamming the Internet to make everyone do what Google / TLS devs want them to do. First, it's coercive. Second, it's in principle spam, even if the cost is affordable in this case. Third, it sets three bad precedents: * Google can do whatever they want * Hijacking user computers for ulterior purposes (by utilizing Chrome) is ok * Spam and coercion are ok. And if you argue it's ok in this instance, you aren't thinking past your nose. Imagine if Symantec or Microsoft tried it; how would people react? Well you don't have to wonder, because they will.

geofft 8y ago
It doesn't set the precedent that Google can do whatever they want. Either they already could because of their size and that's already a problem the world should solve even if they haven't used the power yet, or they can only do this because people think it's a reasonable idea and don't object.
tptacek 8y ago
You have to really want an anti-Google story to find it in this, the bit where Google is using its market position on the server and clientside to help make sure vendors don't break the TLS standard.
- forapurpose 8y ago
  What about the second precedent in the GP, and what about my point, if you argue it's ok in this instance ...?
  - staticassertion 8y ago
    Would you argue against Chrome sending out random LLMNR requests at boot to detect attackers on the network? They aren't "hijacking" computers of users who voluntarily installed chrome - in part due to the promise of a safer browsing experience, which this is all about.
    - forapurpose 8y ago
      > Would you argue against Chrome sending out random LLMNR requests at boot to detect attackers on the network? Good question. No, I wouldn't, because it serves that user directly. Google could argue that the TLS 'GREASE' benefits users, but that benefit, and let's assume it exists, is very indirect: That user won't see any benefit that day, that week, and maybe never; Google is using their users' computers to advocate something that Google thinks is a good idea. To demonstrate GREASE can be taken too far, imagine the extreme case where Google has Chrome send messages to U.S. Congresspeople advocating against some policy - Google could argue that they believe it's in the users' interests, but that would be highly disingenuous. Again, that's extreme and not going to happen. More realistically, imagine Microsoft had Windows 10 insert something in network traffic to compel compatibility with some proprietary technology of theirs. Imagine vendors disagreed about some standard, and different products used GREASE to compete for different outcomes. Where do you draw the line? I think GREASE violates end-user control or autonomy. They become pawns in a standards competition. It's very arrogant of Google and support of it betrays an arrogance perspective here at HN: users are pawns, and their computers are ours to use as we see fit. (It's also intentionally bad engineering, which makes me very uncomfortable.)
      - pdkl95 8y ago
        > That user won't see any benefit that day, that week, and maybe never; I will benefit from this even though I don't use Chrome (or other Google product/services). Reducing traffic manipulation by middleboxes and eliminating passive traffic snooping are important goals, and preserving forward compatibility should increase interoperability with future versions. I benefit from the internet moving back towards the end-to-end principle (smart hosts connected to a dumb network that only routes packets). The additional bandwidth cost is trivial and by definition will not affect anything that follows the spec. > imagine the extreme case ... Again, that's extreme and not going to happen. Speculating about hypothetical problems you admit are not going to happen is a distraction and waste of time. It's possible to make up extreme hypothetical problems afflicting any plan. > imagine Microsoft had Windows 10 insert something in network traffic to compel compatibility I spent a lot of time in the late-90s/early-00s fighting against Microsoft (and others) trying to embrace, extend, and extinguish[1] open standards. That strategy relies on extending an existing protocol with features that are not supported by existing implementations. The goal is to create the wall around a public garden by creating interoperability problems. The only people that might be affected are middleboxes that want to manipulate traffic (good; that was the goal) and incompetent implementations of the spec. The latter probably needs to be fixed (or replaced) anyway because not following the spec that is important for security is a sign that the software probably has other serious bugs and vulnerabilities. I have spent decades fighting for Free Software and against proprietary control of data formats, which are usually a form of rent seeking. Encouraging implementations to follow the spec and ignore unknown elements is unrelated to those concerns. > different products used GREASE to compete for different outcomes. How, precisely, is that supposed to work when (according to the RFC[2]), "Servers MUST correctly ignore unknown values in a ClientHello and attempt to negotiate with one of the remaining parameters." > It's also intentionally bad engineering This is very good engineering. The software industry has been negligent in learning good engineering practices like the importance of designing in tolerance[3] and failing safely. [1] https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis... [2] https://tools.ietf.org/html/draft-ietf-tls-grease-01#section-3.2 https://tools.ietf.org/html/draft-ietf-tls-grease-01#section... [3] https://www.youtube.com/watch?v=9AYuXNz_0Fc https://www.youtube.com/watch?v=9AYuXNz_0Fc
  - notatoad 8y ago
    >what about my point, if you argue it's ok in this instance in this instance, they're doing a good thing. are you arguing that google shouldn't ever do anything, no matter how good it is, because if google is allowed to do things then eventually they might do bad things? that seems absurdly defeatist.
Dylan16807 8y ago
Products putting random data into a few fields is neither coercion nor spam.
inetknght 8y ago
I'm very concerned by it. The day that a programmer can insert additional data as "optional fields" in TLS that can't be inspected without breaking spec? Why can't they be inspected? Because they're "unsupported" Sounds like a great plan. Definitely a great plan. What could go wrong with clients writing out more data than they need to? What could go wrong with clients writing out "garbage data" specifically to make sure that random unsupported data is supported and "ignored"? Nothing wrong at all! /s

geofft 8y ago

It doesn't set the precedent that Google can do whatever they want. Either they already could because of their size and that's already a problem the world should solve even if they haven't used the power yet, or they can only do this because people think it's a reasonable idea and don't object.

tptacek 8y ago

You have to really want an anti-Google story to find it in this, the bit where Google is using its market position on the server and clientside to help make sure vendors don't break the TLS standard.

forapurpose 8y ago
What about the second precedent in the GP, and what about my point, if you argue it's ok in this instance ...?
- staticassertion 8y ago
  Would you argue against Chrome sending out random LLMNR requests at boot to detect attackers on the network? They aren't "hijacking" computers of users who voluntarily installed chrome - in part due to the promise of a safer browsing experience, which this is all about.
  - forapurpose 8y ago
    > Would you argue against Chrome sending out random LLMNR requests at boot to detect attackers on the network? Good question. No, I wouldn't, because it serves that user directly. Google could argue that the TLS 'GREASE' benefits users, but that benefit, and let's assume it exists, is very indirect: That user won't see any benefit that day, that week, and maybe never; Google is using their users' computers to advocate something that Google thinks is a good idea. To demonstrate GREASE can be taken too far, imagine the extreme case where Google has Chrome send messages to U.S. Congresspeople advocating against some policy - Google could argue that they believe it's in the users' interests, but that would be highly disingenuous. Again, that's extreme and not going to happen. More realistically, imagine Microsoft had Windows 10 insert something in network traffic to compel compatibility with some proprietary technology of theirs. Imagine vendors disagreed about some standard, and different products used GREASE to compete for different outcomes. Where do you draw the line? I think GREASE violates end-user control or autonomy. They become pawns in a standards competition. It's very arrogant of Google and support of it betrays an arrogance perspective here at HN: users are pawns, and their computers are ours to use as we see fit. (It's also intentionally bad engineering, which makes me very uncomfortable.)
    - pdkl95 8y ago
      > That user won't see any benefit that day, that week, and maybe never; I will benefit from this even though I don't use Chrome (or other Google product/services). Reducing traffic manipulation by middleboxes and eliminating passive traffic snooping are important goals, and preserving forward compatibility should increase interoperability with future versions. I benefit from the internet moving back towards the end-to-end principle (smart hosts connected to a dumb network that only routes packets). The additional bandwidth cost is trivial and by definition will not affect anything that follows the spec. > imagine the extreme case ... Again, that's extreme and not going to happen. Speculating about hypothetical problems you admit are not going to happen is a distraction and waste of time. It's possible to make up extreme hypothetical problems afflicting any plan. > imagine Microsoft had Windows 10 insert something in network traffic to compel compatibility I spent a lot of time in the late-90s/early-00s fighting against Microsoft (and others) trying to embrace, extend, and extinguish[1] open standards. That strategy relies on extending an existing protocol with features that are not supported by existing implementations. The goal is to create the wall around a public garden by creating interoperability problems. The only people that might be affected are middleboxes that want to manipulate traffic (good; that was the goal) and incompetent implementations of the spec. The latter probably needs to be fixed (or replaced) anyway because not following the spec that is important for security is a sign that the software probably has other serious bugs and vulnerabilities. I have spent decades fighting for Free Software and against proprietary control of data formats, which are usually a form of rent seeking. Encouraging implementations to follow the spec and ignore unknown elements is unrelated to those concerns. > different products used GREASE to compete for different outcomes. How, precisely, is that supposed to work when (according to the RFC[2]), "Servers MUST correctly ignore unknown values in a ClientHello and attempt to negotiate with one of the remaining parameters." > It's also intentionally bad engineering This is very good engineering. The software industry has been negligent in learning good engineering practices like the importance of designing in tolerance[3] and failing safely. [1] https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis... [2] https://tools.ietf.org/html/draft-ietf-tls-grease-01#section-3.2 https://tools.ietf.org/html/draft-ietf-tls-grease-01#section... [3] https://www.youtube.com/watch?v=9AYuXNz_0Fc https://www.youtube.com/watch?v=9AYuXNz_0Fc
- notatoad 8y ago
  >what about my point, if you argue it's ok in this instance in this instance, they're doing a good thing. are you arguing that google shouldn't ever do anything, no matter how good it is, because if google is allowed to do things then eventually they might do bad things? that seems absurdly defeatist.

Dylan16807 8y ago

Products putting random data into a few fields is neither coercion nor spam.

inetknght 8y ago

I'm very concerned by it. The day that a programmer can insert additional data as "optional fields" in TLS that can't be inspected without breaking spec? Why can't they be inspected? Because they're "unsupported" Sounds like a great plan. Definitely a great plan. What could go wrong with clients writing out more data than they need to? What could go wrong with clients writing out "garbage data" specifically to make sure that random unsupported data is supported and "ignored"? Nothing wrong at all! /s