I'm not yolkedgeek but I can give my own answer: EDN has tags. Tags start with `#` and are followed by a symbol (which is a lot like an identifier except that a lot of punctuation is allowed in symbols, because EDN derives from Lisp syntax rules). The `/` character is used for namespacing, and a user-defined tag must use a namespace. The tag meaning is application-defined, but there are a couple standard tags with well-defined meanings:
#inst "1985-04-12T23:20:50.52Z" = an instant / timestamp in RFC 3339 format
#uuid "f81d4fae-7dec-11d0-a765-00a0c91e6bf6" = a GUID/UUID
More tags could be defined by the standard later, because the entire unprefixed namespace is reserved. But just having a well-defined way to represent timestamps and UUIDs is an immense win over JSON, where you have to somehow know (based on what you were expecting to receive) that this string should be parsed as a timestamp or a GUID.
Also, user-defined tags will often be used to represent a class:
#myapp/Person {:first "Fred" :last "Mertz"}
Again, no need to know (based on what you were expecting) that this particular object is an instance of Person; the data transfer format tells you what class it is. JSON has to add a field, and what field it is will vary from application to application so it's usually not possible to write a universal parser. One server might generate { "__type": "Person", "first": "Fred", "last": "Mertz } while another one does { "$$class": "Person", "first": "Fred", "last": "Mertz }, for example.
EDN also has syntax defined for sets, but that's a smaller win over JSON, because it's not often necessary to declare that something is a set. Still, there are times it's helpful; it's certainly not a bad thing to have a set syntax.
Also, EDN has comments built in to the system. Two kinds, one line-based comment (useful for actual comments, e.g. when you use EDN as a config format), and one that comments out the next thing in the file (useful for temporarily commenting out an entire section with a single token, or for removing ONE item temporarily from a list that's all on the same line so line-based comments are difficult). Because Douglas Crockford didn't envision JSON as being used for config, he forbade comments in JSON, and people have been coming up with competing proposals for putting comments back in ever since. (Thankfully, nearly all the proposals interoperate, because all of them sensibly use Javascript comment syntax, so it doesn't matter if the file is JSONC or HuJSON or JSON5, the comment syntax is the same).
But the biggest win for EDN is tags, which can convey type information outside the data structure. JSON has to use something inside the data structure to convey type information, and there's always that small chance that the name chosen (__type or $$class or whatever) will collide with a property of the actual object that was supposed to be serialized.
I get tags and atoms. It seems like the problem with class serialization is somewhat arbitrary though. It seems like both sides need the object schema ahead of time, in which case the schema can flag how it sdould be IDd / tagged.
I also wonder if atoms can be reduced for low-bandwidth transmission. Naïvly, you could just prepend a lookup table for multiple-use atoms.
I guess it seems more like niche, additional features when GGP seemed to be claiming a big step up.
I haven't used EDN, but I know YAML has an equivalent feature, and that had been a security issue in some instances because it deserialized into objects the system wasn't expecting. Perhaps their deserializer had learned from that doesn't have that issue?
Haven't used EDN myself but from a read through the docs, I'm pretty sure that on user tags, the deserializer just says "Here's the tag, and here's the object it was tagging" and lets the consuming code decide what to do with the tag. (And on canonical tags like dates and GUIDs, there's no security risk to deserializing them as the recipient language's version of timestamps and UUIDs).
Actually, https://github.com/edn-format/edn says "It is envisioned that a reader implementation will allow clients to register handlers for specific tags. Upon encountering a tag, the reader will first read the next element (which may itself be or comprise other tagged elements), then pass the result to the corresponding handler for further interpretation, and the result of the handler will be the data value yielded by the tag + tagged element, i.e. reading a tag and tagged element yields one value. This value is the value to be returned to the program and is not further interpreted as edn data by the reader."
So if the client is specifying the handlers, then it's up to the client's handler implementation to sanitize the incoming data before instantiating the objects. And since the client supplies the list of handlers, the only tags that will be handled are ones the client was expecting. Assuming sanitizing the incoming data before instantiating objects is done correctly, I don't see any way for that to become a security issue.
The idea isn't to comprehensively make malicious code impossible - the idea is to make it difficult to sneak in. If the NSA wants to spend 500 billion$ to compromise an NPM package, there's very little we can do. But if waiting 3 days for security scans catch even 10% of malicious packages, that 's 10% fewer incidents everyone else has to deal with. And now people pwning maintainers must be much more sophisticated so their attacks are entirely undetected for that period.
I just hope that the companies who currently perform security scans for free/for exposure have a sustainable business model. Once such a company gains reputation, there's diminishing returns in headlines currency.
I don't think anyone is saying cooldowns are the only thing you need - just that it's a 30sec change that should harden your code.
Also, most malicious versions seem to be detected by tools scanning new packages. People updating without cooldowns probably aren't manualy inspecting diffs. Giving tools more time to detect things seems pretty obviously good to me. Add to that maintainers reporting they've been pwned, and the floor for sneaking malicious code is much higher.
I legit do something similar to this for my ADHD. I make 6,8, or 10 item long lists of tasks, then roll a die to choose what to do. I pair it with a similar list of rewards that I can roll on when I complete a task.
Love it! I thought about allowing users to add their task lists as an A/B test but decided to keep the original version as MVP to keep it separate from conventional to-do lists.
For how long you`ve been doing this? Curious about long-term benefits if you don`t mind sharing.
I don't do it all the time, usually just when I feel swamped with a bunch of different tasks. I also try to time box it, so no matter what I roll I work on it for a predictable length of time. I think the most effective part for me is not letting myself say no to whatever comes up - I just have to do my best. I feel like it's really helpful when I'm struggling to just set down and focus on one thing.
I am thinking about adding the brain dump to the project future sscope to ease cognitive load and willingless to switch to a new shiny idea lol
Thanks a lot for sharing your experience!
reply