13 ms·

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 volu

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
- staticassertion 8y ago
  I disagree with the idea that users won't see benefits - the benefit is that upgrades to a critical protocol can be rolled out more smoothly in the face of compliant middleware. This benefit will be significant for end users. Sending messages to Congress would be very different - that's squarely outside of the purview of a browser. TLS is not. As for Microsoft having Windows 10 insert things to support a proprietary technology, again, this is a flawed analogy - it's simply not what's happening here. Why draw the line if we know that we haven't crossed it? You have put forth two cases that seem obviously on the other side. This case seems obviously on the 'we good' side. Would you say A/B testing means 'users are pawns'? I really disagree with that. Again, this is all in the interest of end users who have voluntarily installed this software, at least in part because of the secure reputation.

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
staticassertion 8y ago
I disagree with the idea that users won't see benefits - the benefit is that upgrades to a critical protocol can be rolled out more smoothly in the face of compliant middleware. This benefit will be significant for end users. Sending messages to Congress would be very different - that's squarely outside of the purview of a browser. TLS is not. As for Microsoft having Windows 10 insert things to support a proprietary technology, again, this is a flawed analogy - it's simply not what's happening here. Why draw the line if we know that we haven't crossed it? You have put forth two cases that seem obviously on the other side. This case seems obviously on the 'we good' side. Would you say A/B testing means 'users are pawns'? I really disagree with that. Again, this is all in the interest of end users who have voluntarily installed this software, at least in part because of the secure reputation.