I know async-signal-safety is particularly important for, you know, signal handlers. But aside from those, and the multi-threading use case you describe, is there another use case where calling non async-signal-safe code from inside this module would lead to issues (that isn't covered in the new limitations)?
I can add another limitation is issues can transpire if the code you run in `callable()` isn't async-signal-safe, but I'd like to offer a few additional examples of gotchas or surprises to point out there.
Port scanning from a web page, combined with DNS rebinding, can present a really nasty attack, and can effect an entire private network, not just localhost.
What a great read! I've never thought about how the way we experience the surface of the earth as 2D manifold of a 3D space, and how up until recently (relatively speaking) this was unknown.
It's interesting to expand on this idea and realize that maybe we are making the same mistake again, and that from our local perspective the universe is 3D, when in reality, it's a 3D manifold of a higher dimensional space.
One thing I am still unclear of though, is that isn't this proven to be the case? Is it not true that we are provably living in at least a 4D space, where time is the fourth dimension? We can observe its existence but cannot move freely through it and are confined to free transformations only in 3D space? In this way, aren't we living in a 3D manifold in a 4D space? So maybe then the question is are we living in a 3D manifold of a +4D space?
If memory serves me Firefox cookies are stored unencrypted in an sqlite database with user level permissions. Haven't dug too deep, so I could be missing something, but last time I peaked down the rabbit hole that's what I remember.
#1, good call!
#2, usually I am 100% in agreement. But referer vs referrer in the HTTP spec is a special case. I chose to do this as referer is misspelled in the spec itself.
After a bit of prodding I caved and bought an aux cable, but I've wondered the same about the audio -> USB cable. It think it's FTDI so I think a clever person might be able to figure it out. If you get anywhere with this let me know!
Thanks mate! I appreciate that. I was looking for a way to describe it that seemed as down to earth as possible. Actually I was trying to go for that with most of the documentation so far (and what will be coming). It's not always so easy with stuff this technical but it's good to hear it's working for some people.
That's a great idea! The protocol can be implemented entirely separate from this first TypeScript client application. If anyone out there has gnuradio experience, I'd love to chat with them / offer support. I'd imagine the more folks use it the more we'd learn what modifications to v1 of the protocol would be useful.
While it doesn't call out encryption by name it more broadly prohibits "messages encoded for the purpose of obscuring their meaning." I take that to include both encryption and obfuscation methods like steganography.