4 ms·

One approach to guard against Hyrum’s Law is GREASE (aka “Generate Random Extensions And Sustain Extensibility” used in the TLS 1.3 protocol) i.e. behavior rand

One approach to guard against Hyrum’s Law is GREASE (aka “Generate Random Extensions And Sustain Extensibility” used in the TLS 1.3 protocol) i.e. behavior randomization to avoid inadvertent dependencies on unspecified behavior: https://textslashplain.com/2020/05/18/a-bit-of-grease-keeps-the-web-moving/ https://textslashplain.com/2020/05/18/a-bit-of-grease-keeps-... What are other approaches?

jackblemming 3y ago
Telling people who depended on probably internal behavior that wasn’t an explicit part of your contract to fuck off when they whine about you changing something.
- salawat 3y ago
  You don't get to decide what is and isn't an implementation detail. And lets be real. There is no contract, and any one that is made will inevitably be broken.
  - kazinator 3y ago
    That depends entirely on the economics of the situation. Like who violates the contract, and how much business they represent. Or other measure of their importance. Does the C library change break a major distro? Or just some obscure program with three users?
- summerlight 3y ago
  When the clients have the power (e.g. a team that contributes to 90% of company's revenue), breaking the contract is often non-option from the beginning.
- c0pium 3y ago
  Ah yes, the “you’re holding it wrong” strategy.
aaron695 3y ago
> “Generate Random Extensions And Sustain Extensibility” This should get a re-submit on HN (0 comments - https://news.ycombinator.com/item?id=16149534 https://news.ycombinator.com/item?id=16149534 4 years ago) I wonder if it would allow for easter eggs again. Would the fabled story between Larry Osterman and Raymond Chen's Exchange POP3 server easter egg fall within GREASE - https://learn.microsoft.com/en-us/archive/blogs/larryosterman/why-no-easter-eggs https://learn.microsoft.com/en-us/archive/blogs/larryosterma...
- nkurz 3y ago
  I tried to figure out how it credit it to you, but it was too complicated, so just I posted it here as me: https://news.ycombinator.com/item?id=39416277 https://news.ycombinator.com/item?id=39416277
deleted 3y ago
[deleted]
dgacmu 3y ago
The Go hash table approach is similar to this: it's randomizedish but not strongly random enough to depend on it being actually random... https://dev.to/wallyqs/gos-map-iteration-order-is-not-that-random-mag https://dev.to/wallyqs/gos-map-iteration-order-is-not-that-r... (Which I find a hilarious second order example of Hyrum's law - if you add true randomness to prevent people from depending on the iteration order, they might use it as a way to randomly access items in the map!)
- tialaramex 3y ago
  Matt Kulukundis (sp?) mentions this problem is his talk about Google's rather fancier Swiss tables. At that point their debug builds would do a "coin toss" with 50.3% chance to be heads during hash table insertion and he expected some idiots would use that to generate random bits then be annoyed if it breaks. I believe in production it's entirely seeded from ASLR, so you're actually leaking address layout info if you try to use these bits as entropy instead of just to make the hash table defeat your bad unit tests.
  - jdoerrie 3y ago
    Here's a link to that talk and mentioning of the 50.3%: https://youtu.be/ncHmEUmJZf4?t=2610 https://youtu.be/ncHmEUmJZf4?t=2610
- saghm 3y ago
  This was mostly annoying because Go doesn't really provide any ordered map in std (and for while didn't give you generics, which are needed to make a general-purpose one that's perfomant). I feel like the best response to people relying on the order of iteration is to recognize that as a valid need an provide it via a separate type.
  - Hyrum_Website 3y ago
    Agreeing with kookamamie, yau8edq12i, and marliechiller Hyrum and his dedicated self-proclaiming website reminded me of the gracelessness in the 3rd example of r/iamverysmart: Self-quoting
tanx16 3y ago
Our team went with a similar approach when refactoring Protobuf debug APIs (https://bughunters.google.com/blog/6405366705946624/fixing-debug-log-leakage-with-safe-coding https://bughunters.google.com/blog/6405366705946624/fixing-d...). People were relying on debug output and trying to parse it, so in the new implementation we threw up big warning flags and made the output unstable so that you couldn't make the mistake. The key lesson to take away is: if you want something to be an implementation detail, make sure to have multiple differing implementations :)
waynesonfire 3y ago
> guard against Hyrum’s Law Why bother? We're not even able to guard against well establish contracts from changing and breaking compatibility.
deleted 3y ago
[deleted]
djha-skin 3y ago
Multiple implementations of the same interface. When people don't know which implementation will be used, they tend to stick to the standard or the documentation. We see this in places like the C language or in Common Lisp. Library writers must take into account that the implementation they use their library on may not be the same as the implementation their users will use.

jackblemming 3y ago

Telling people who depended on probably internal behavior that wasn’t an explicit part of your contract to fuck off when they whine about you changing something.

salawat 3y ago
You don't get to decide what is and isn't an implementation detail. And lets be real. There is no contract, and any one that is made will inevitably be broken.
- kazinator 3y ago
  That depends entirely on the economics of the situation. Like who violates the contract, and how much business they represent. Or other measure of their importance. Does the C library change break a major distro? Or just some obscure program with three users?
summerlight 3y ago
When the clients have the power (e.g. a team that contributes to 90% of company's revenue), breaking the contract is often non-option from the beginning.
c0pium 3y ago
Ah yes, the “you’re holding it wrong” strategy.

aaron695 3y ago

> “Generate Random Extensions And Sustain Extensibility” This should get a re-submit on HN (0 comments - https://news.ycombinator.com/item?id=16149534 https://news.ycombinator.com/item?id=16149534 4 years ago) I wonder if it would allow for easter eggs again. Would the fabled story between Larry Osterman and Raymond Chen's Exchange POP3 server easter egg fall within GREASE - https://learn.microsoft.com/en-us/archive/blogs/larryosterman/why-no-easter-eggs https://learn.microsoft.com/en-us/archive/blogs/larryosterma...

nkurz 3y ago
I tried to figure out how it credit it to you, but it was too complicated, so just I posted it here as me: https://news.ycombinator.com/item?id=39416277 https://news.ycombinator.com/item?id=39416277

deleted 3y ago

[deleted]

dgacmu 3y ago

The Go hash table approach is similar to this: it's randomizedish but not strongly random enough to depend on it being actually random... https://dev.to/wallyqs/gos-map-iteration-order-is-not-that-random-mag https://dev.to/wallyqs/gos-map-iteration-order-is-not-that-r... (Which I find a hilarious second order example of Hyrum's law - if you add true randomness to prevent people from depending on the iteration order, they might use it as a way to randomly access items in the map!)

tialaramex 3y ago
Matt Kulukundis (sp?) mentions this problem is his talk about Google's rather fancier Swiss tables. At that point their debug builds would do a "coin toss" with 50.3% chance to be heads during hash table insertion and he expected some idiots would use that to generate random bits then be annoyed if it breaks. I believe in production it's entirely seeded from ASLR, so you're actually leaking address layout info if you try to use these bits as entropy instead of just to make the hash table defeat your bad unit tests.
- jdoerrie 3y ago
  Here's a link to that talk and mentioning of the 50.3%: https://youtu.be/ncHmEUmJZf4?t=2610 https://youtu.be/ncHmEUmJZf4?t=2610
saghm 3y ago
This was mostly annoying because Go doesn't really provide any ordered map in std (and for while didn't give you generics, which are needed to make a general-purpose one that's perfomant). I feel like the best response to people relying on the order of iteration is to recognize that as a valid need an provide it via a separate type.
- Hyrum_Website 3y ago
  Agreeing with kookamamie, yau8edq12i, and marliechiller Hyrum and his dedicated self-proclaiming website reminded me of the gracelessness in the 3rd example of r/iamverysmart: Self-quoting

tanx16 3y ago

Our team went with a similar approach when refactoring Protobuf debug APIs (https://bughunters.google.com/blog/6405366705946624/fixing-debug-log-leakage-with-safe-coding https://bughunters.google.com/blog/6405366705946624/fixing-d...). People were relying on debug output and trying to parse it, so in the new implementation we threw up big warning flags and made the output unstable so that you couldn't make the mistake. The key lesson to take away is: if you want something to be an implementation detail, make sure to have multiple differing implementations :)

waynesonfire 3y ago

> guard against Hyrum’s Law Why bother? We're not even able to guard against well establish contracts from changing and breaking compatibility.

deleted 3y ago

[deleted]

djha-skin 3y ago

Multiple implementations of the same interface. When people don't know which implementation will be used, they tend to stick to the standard or the documentation. We see this in places like the C language or in Common Lisp. Library writers must take into account that the implementation they use their library on may not be the same as the implementation their users will use.