4 ms·

Completely agree. I could actually get a lot of use out of a tool like this, but the fact that even the VSCode extension sends the JSON to their servers and ope

by Mogzol 4y ago

Completely agree. I could actually get a lot of use out of a tool like this, but the fact that even the VSCode extension sends the JSON to their servers and opens it at a publicly accessible URL makes this a no-go for me. I wouldn't recommend anyone use this for any remotely sensitive data.

chii 4y ago
the extension apparently can be configured to use a locally running instance of the server. But yes, by default it uses the remote version, and thus you post publicly the json, which may or may not be ideal depending on what you're doing.
- Mogzol 4y ago
  The fact that it needs a server at all seems unnecessary. It's all written in JavaScript, and isn't doing anything that couldn't be done in a browser, I see no reason why this can't be an entirely client-side application.
  - mholt 4y ago
    Processing multi-GB files in the browser is... fun. Doing that kind of thing on a server is easier. *I'm not justifying doing it on the server, especially for an application like this where yes: it can be done in the client.* But I do sympathize because I know from experience why it's easier to do it server-side, without any conspiracies. I wrote Papa Parse[0] about 10 years ago, and back then at least, it was extremely difficult to stream large files in an efficient, reliable way. Web Workers make things slightly better, but there's so many issues with large-scale local compute in a browser tab. A few examples: - https://stackoverflow.com/questions/24708649/why-does-web-worker-performance-sharply-decline-after-30-seconds https://stackoverflow.com/questions/24708649/why-does-web-wo... (the answer actually came from Google+ which is still linked to, but no longer available; fortunately I summarized it in my post) - https://stackoverflow.com/questions/27081858/how-can-i-make-a-really-long-string-using-indexeddb-without-crashing-the-browser https://stackoverflow.com/questions/27081858/how-can-i-make-... You get deep enough into the weeds and eventually you realize you can make it work cross-browser if you know which browser you're using (YES, User-Agent does matter for things like this) and call you crazy for trying to find out: - https://stackoverflow.com/questions/27084036/how-can-i-reliably-detect-the-browser-without-using-window-navigator https://stackoverflow.com/questions/27084036/how-can-i-relia... Despite all this, I *100%* agree and local-only processing is also a hard-rule for me as well. (That's why JSON-to-Go[1] does it all client-side. `go fmt` event compiles to WASM and runs in the browser!) [0]: https://www.papaparse.com/ https://www.papaparse.com/ [1]: https://mholt.github.io/json-to-go/ https://mholt.github.io/json-to-go/
    - rob74 4y ago
      Ok, I think I get what you're saying - this is a VS Code extension, but because VS Code is an Electron application, it's still "running in a browser"?
    - simplotek 4y ago
      > Processing multi-GB files in the browser is... fun. Doing that kind of thing on a server is easier. This sounds like a strawman. Not everyone wrangles multi-GB files, let alone JSON documents. Those who do are already readily aware of the implications. I mean,some popular text editors even struggle with multi-GB of plain text files. You don't need a server to handle JSON. There is no excuse.
      - hutzlibu 4y ago
        "You don't need a server to handle JSON. There is no excuse." No technical excuse, but lots of buisness reasons I guess.
- rob74 4y ago
  "the extension apparently can be configured to use a locally running instance of the server" - well that sounds needlessly complicated, I mean, the code could be implemented directly in the extension (I know, that's probably easier than it sounds if you are trying to maintain both the extension and the online version with the same code base). "you post publicly the json, which may or may not be ideal depending on what you're doing" - that's never ideal, it's just a smaller problem (if the JSON is publicly available anyway) or a much bigger problem (if it's sensitive personal data).
  - TeMPOraL 4y ago
    > or a much bigger problem (if it's sensitive personal data). Personal data is a red herring. It's not the only thing that matters. For starters, using this at work with anything not explicitly public is likely a violation of your contract. In some contexts, it may even be gross misconduct or illegal and potentially exposing your employer to large fines. And, in general, I'd say a tool like this that comes without explicit, bold warning that it's shipping data off your machine, is just being rude.
    - pletnes 4y ago
      I agree, mostly. But since when isn’t it obvious that posting data with a browser will send that data somewhere? And the users here are (from what I can tell) developers. I think this is a cool tool for public data and obviously I can’t paste private data sets on any public website, ever.
      - TeMPOraL 4y ago
        It's not obvious ever since some of those tools started to blur the line; there are plenty of such little utilities that do everything client-side, or at least claim so. I don't use them with anything but public data, as it takes one mistake or one silent update for the data to get shipped off my machine, but there's a whole generation of devs now who were growing up with webapps and online-first software, so I can easily see some developers making this mistake. Plus, they offer a VS Code extension. It's not so obvious that it's just the same public website underneath. Additionally, developers who understand those concerns kind of expect that other developers also understand them, and thus would not create an on-line tool like this in the first place.

by Mogzol 4y ago

chii 4y ago

the extension apparently can be configured to use a locally running instance of the server. But yes, by default it uses the remote version, and thus you post publicly the json, which may or may not be ideal depending on what you're doing.

Mogzol 4y ago
The fact that it needs a server at all seems unnecessary. It's all written in JavaScript, and isn't doing anything that couldn't be done in a browser, I see no reason why this can't be an entirely client-side application.
- mholt 4y ago
  Processing multi-GB files in the browser is... fun. Doing that kind of thing on a server is easier. *I'm not justifying doing it on the server, especially for an application like this where yes: it can be done in the client.* But I do sympathize because I know from experience why it's easier to do it server-side, without any conspiracies. I wrote Papa Parse[0] about 10 years ago, and back then at least, it was extremely difficult to stream large files in an efficient, reliable way. Web Workers make things slightly better, but there's so many issues with large-scale local compute in a browser tab. A few examples: - https://stackoverflow.com/questions/24708649/why-does-web-worker-performance-sharply-decline-after-30-seconds https://stackoverflow.com/questions/24708649/why-does-web-wo... (the answer actually came from Google+ which is still linked to, but no longer available; fortunately I summarized it in my post) - https://stackoverflow.com/questions/27081858/how-can-i-make-a-really-long-string-using-indexeddb-without-crashing-the-browser https://stackoverflow.com/questions/27081858/how-can-i-make-... You get deep enough into the weeds and eventually you realize you can make it work cross-browser if you know which browser you're using (YES, User-Agent does matter for things like this) and call you crazy for trying to find out: - https://stackoverflow.com/questions/27084036/how-can-i-reliably-detect-the-browser-without-using-window-navigator https://stackoverflow.com/questions/27084036/how-can-i-relia... Despite all this, I *100%* agree and local-only processing is also a hard-rule for me as well. (That's why JSON-to-Go[1] does it all client-side. `go fmt` event compiles to WASM and runs in the browser!) [0]: https://www.papaparse.com/ https://www.papaparse.com/ [1]: https://mholt.github.io/json-to-go/ https://mholt.github.io/json-to-go/
  - rob74 4y ago
    Ok, I think I get what you're saying - this is a VS Code extension, but because VS Code is an Electron application, it's still "running in a browser"?
  - simplotek 4y ago
    > Processing multi-GB files in the browser is... fun. Doing that kind of thing on a server is easier. This sounds like a strawman. Not everyone wrangles multi-GB files, let alone JSON documents. Those who do are already readily aware of the implications. I mean,some popular text editors even struggle with multi-GB of plain text files. You don't need a server to handle JSON. There is no excuse.
    - hutzlibu 4y ago
      "You don't need a server to handle JSON. There is no excuse." No technical excuse, but lots of buisness reasons I guess.
rob74 4y ago
"the extension apparently can be configured to use a locally running instance of the server" - well that sounds needlessly complicated, I mean, the code could be implemented directly in the extension (I know, that's probably easier than it sounds if you are trying to maintain both the extension and the online version with the same code base). "you post publicly the json, which may or may not be ideal depending on what you're doing" - that's never ideal, it's just a smaller problem (if the JSON is publicly available anyway) or a much bigger problem (if it's sensitive personal data).
- TeMPOraL 4y ago
  > or a much bigger problem (if it's sensitive personal data). Personal data is a red herring. It's not the only thing that matters. For starters, using this at work with anything not explicitly public is likely a violation of your contract. In some contexts, it may even be gross misconduct or illegal and potentially exposing your employer to large fines. And, in general, I'd say a tool like this that comes without explicit, bold warning that it's shipping data off your machine, is just being rude.
  - pletnes 4y ago
    I agree, mostly. But since when isn’t it obvious that posting data with a browser will send that data somewhere? And the users here are (from what I can tell) developers. I think this is a cool tool for public data and obviously I can’t paste private data sets on any public website, ever.
    - TeMPOraL 4y ago
      It's not obvious ever since some of those tools started to blur the line; there are plenty of such little utilities that do everything client-side, or at least claim so. I don't use them with anything but public data, as it takes one mistake or one silent update for the data to get shipped off my machine, but there's a whole generation of devs now who were growing up with webapps and online-first software, so I can easily see some developers making this mistake. Plus, they offer a VS Code extension. It's not so obvious that it's just the same public website underneath. Additionally, developers who understand those concerns kind of expect that other developers also understand them, and thus would not create an on-line tool like this in the first place.