3 ms·

Repeatedly calling it insecure and not to spec when it’s secure and it does the exact same thing unless given unusual input, and is as a ponyfill to ensure the

Repeatedly calling it insecure and not to spec when it’s secure and it does the exact same thing unless given unusual input, and is as a ponyfill to ensure the dev is aware of its source when calling it. He also said he has relevant experience when questioned and showed an irrelevant example to support that claim. https://github.com/ungap/raw-json/issues/6#issuecomment-2434575188 https://github.com/ungap/raw-json/issues/6#issuecomment-2434...

lolinder 2y ago
> calling it insecure and not to spec when it’s secure and it does the exact same thing unless given unusual input See, the "unless given unusual input" thing is part of where MDN was in the right and OP is in the wrong. A polyfill/ponyfill that isn't perfectly spec-compliant can be useful, but it's reasonable for MDN to refuse to endorse it, given that their pages describe the specs. And to try to argue that it still counts as spec compliant when it doesn't handle edge cases is nonsense—the edge cases are why we have specs! If we didn't have to standardize even the edge cases an informal description of the solution would do the trick.
- deleted 2y ago
  [deleted]
- benatkin 2y ago
  [flagged]
  - andrepd 2y ago
    Okay! So you decided beforehand that "MDN" is in the wrong, and now you've decided to ignore factual info to the contrary.
  - deleted 2y ago
    [deleted]
  - deleted 2y ago
    [deleted]
  - raincole 2y ago
    That thread made MDN look good. I honestly can't see myself handling the situation as professionally as the MDN guy.
jkrems 2y ago
Being spec compliant means being compliant with the entire spec, not just a "reasonable subset of the spec", picked by the author of the ponyfill/polyfill. And being secure only in the presence of normal inputs is... pretty meaningless afaict? Anything is secure if the inputs are "nice to the implementation". That isn't a typical bar for "it's secure". Whether every use case that just wants to roundtrip BigInt through JSON _needs_ a fully spec compliant & generally secure solution is a different question. But at that point it's about picking a solution for a related use case, not about actually standing in for the upcoming browser feature.

lolinder 2y ago

> calling it insecure and not to spec when it’s secure and it does the exact same thing unless given unusual input See, the "unless given unusual input" thing is part of where MDN was in the right and OP is in the wrong. A polyfill/ponyfill that isn't perfectly spec-compliant can be useful, but it's reasonable for MDN to refuse to endorse it, given that their pages describe the specs. And to try to argue that it still counts as spec compliant when it doesn't handle edge cases is nonsense—the edge cases are why we have specs! If we didn't have to standardize even the edge cases an informal description of the solution would do the trick.

deleted 2y ago
[deleted]
benatkin 2y ago
[flagged]
- andrepd 2y ago
  Okay! So you decided beforehand that "MDN" is in the wrong, and now you've decided to ignore factual info to the contrary.
- deleted 2y ago
  [deleted]
- deleted 2y ago
  [deleted]
- raincole 2y ago
  That thread made MDN look good. I honestly can't see myself handling the situation as professionally as the MDN guy.

jkrems 2y ago

Being spec compliant means being compliant with the entire spec, not just a "reasonable subset of the spec", picked by the author of the ponyfill/polyfill. And being secure only in the presence of normal inputs is... pretty meaningless afaict? Anything is secure if the inputs are "nice to the implementation". That isn't a typical bar for "it's secure". Whether every use case that just wants to roundtrip BigInt through JSON _needs_ a fully spec compliant & generally secure solution is a different question. But at that point it's about picking a solution for a related use case, not about actually standing in for the upcoming browser feature.