A service worker would work fine; the connection would be instantiated from the SW and each window/worker could communicate with it via navigator.serviceWorker.
Instead of adding a non-standard API to opt-out of existing networking functionality, it would be great to see a lower-level networking primitive to unlock these kinds of use cases. I wrote more (with a proof-of-concept) here: https://readable.writable.stream
No. That's the whole point of using JSON.parse() instead of eval(). JSON is defined as a non-executing subset of JavaScipt syntax, one that contains only literal expressions. JSON.parse() will only parse valid JSON.
This is why, for instance, there's no native Date format in JSON. Dates in JavaScript require running a constructor -- new Date() -- so they aren't in JSON.
That would concern me too potentially, though if there isn't one already it should be easy to implement a switch that would turn this part of the behaviour off.
It looks very interesting to me from the point of view of dealing with certain data types better (at all, in fact), and handling circular references.
I was thinking more along the lines of turning it off at the generation side: only including anything in the persisted state that is safe.
Trying to detect the unsafe parts so they could be turned off after that point would be impossible as you suspect (the task would be constrained by the halting problem, https://en.wikipedia.org/wiki/Halting_problem).
It seems like it theoretically shouldn't be too hard to add the ability to validate that the data is a valid lave output if you're concerned about that. That more or less leaves only the issue of anonymous functions in the data being replaced with malicious functions, but frankly the only reason to be serializing functions is if they're user input, otherwise you should instead be serializing function name/key strings or some other well-defined form of function references and/or arguments.
Any type of code-serialization tool will be vulnerable to injection. This is why use of pickle is often discouraged in Python, in favor of serialization formats which don't deserialize to code. Anything that marks "valid output of the tool" could just as easily be produced by an attacker who uses the tool to serialize their malicious code, and even signing/secret-token systems aren't a guarantee since it's so incredibly easy to build or use them the wrong way.
I meant that your code could parse the supposed lave code before running it to verify that it is limited to the known lave constructs (which does not include arbitrary code execution). It would quite slow but enough to make it somewhat safe against an attacker providing malicious lave code.
If lave generates a well defined sublanguage, I don't think parsing would need to be much slower than parsing JSON. It would just be an extended JSON parser that happens to parse executable JavaScript.
Absolutely. The downside of running a full-blown eval() exists in JSON too, it's just that the eval() there is taking place in the reviver function, which requires a lot more coordination than a self-contained file.
As far as efficiency, I'd think for most uses the issue would be on the JSON.parse end. In this case, lave might be more efficient, since JSON reviving often ends up creating temporary objects that need to GC'ed after reification.
I really like the idea of using Google Spreadsheets as a quick and familiar GUI for entry or querying on data sets, as long as you understand the tradeoffs (write latency isn't great and they max out at 400,000 cells).
But this is especially nice when you build a layer on top of Google reduces lock-in, instead of adding another proprietary API. This is what I did with sheet-down[1], which turns a Google Spreadsheet into a LevelDB-compatible data store that can be swapped out with a file system or other compatible backend[2] once you outgrow Google.
How do you handle type constraints? For example, how do you prevent users from inputing text in to number fields? I know Google Sheets has validators, but I don't know of any way to restrict someone from changing those validations while also providing the ability to input data.
Really curious, because I'd love to use something like this in our app.
My situation is for an intranet environment, so I suppose I could just ask nicely that they don't change validations. But chances are most of my target users aren't familiar enough with Google Spreadsheets to even get that far.
Grammar & honorifics/formality are two separate subjects. I'm not fluent in Japanese by any stretch of the imagination, but I know the basics of grammar while I know basically nothing about formal speech/informal speech.
