← Back to context

Comment by Veserv

3 days ago

Oh indeed, if we just redefine words in the fine print then we can commit fraud with impunity.

Please enlighten me how that blurb supports the common reading of the claim: Your data, … secure. Note that and is a additive conjunction, so the components can be safely examined separately.

A regular person would assume that means your data is secure against tampering and disclosure. If you then say: “lol, jk we do not do anything related to securing your data” in the fine print then in a reasonable society you should be required to remove that more prominent false large print.

You can always go back and reword your large print to be more accurate without making deceptive claims to your benefit. Weird how the deception is always beneficial.

Security is an umbrella term. You can't just assume that secure things are private--you have to make the determination in context with whatever kind of thing it is.

The primary goals of a system like radicle are:

- spread the word

- don't let anybody alter it

If you ask if it's secure, you should assume you'll get an answer related to those purposes.

If you got a sunburn while standing in line for a water slide, you wouldn't say that the slide is unsafe, even though being burned is a hell of a departure from "safety". You'd have to be a little more specific.

  • https://www.ibm.com/think/topics/data-security

    https://www.fortinet.com/resources/cyberglossary/data-securi...

    https://en.wikipedia.org/wiki/Data_security

    https://www.nccoe.nist.gov/data-security

    etc

    all of these start with “unauthorized access” to define this term. can you please explain how open access to private repositories is not unauthorized access and how you can’t expect your data moving to private repositories to be private?

    • https://en.wikipedia.org/wiki/Information_security#Key_conce... says this:

      > Information security's primary focus is the balanced protection of data confidentiality, integrity, and availability

      ..and radicle.dev does nothing to suggest confidentiality is a focus. Words like "private" or "encrypted" don't appear on their front page.

      When I saw this, I was surprised because I didn't even know they supported private repos. I just don't understand why you'd want private repositories on a peer to peer protocol. The whole point is to get away from all of the problematic things that stem from having a single point of control/failure and the hierarchies that follow therefrom. Private repositories means that you're re-implementing the very problems that you're presumably using something like Radicle to get away from, now at the application layer instead. If you can tolerate having an admin that may later be unavailable or untrustworthy such that you're locked out, why not just use github?

      It's like private blog posts on wordpress. Yeah, if the feature is in there it should work but projects like these encapsulate a certain perspective, and if they're run by a small number of technologists who clearly in it because they care, then I think it's reasonable to evaluate their success based on whether they address the primary problem they're up against, not whether they have a bug in some feature they tacked on as an afterthought.

      Anybody can set up encryption on a link. Shame on them for forgetting to do that, but radicle has much more ambitious goals. If they need more help than they're getting for some of the mundane stuff, well I'm not going to judge them too harshly for that.