in reply to Re^3: RFC: self hosting Perl 6 string wiki
in thread RFC: self hosting Perl 6 string wiki

Hey Moritz,

Thankyou again. I hope you are enjoying this dialog -- I sure appreciate it. :)

That doesn't account for attacks that can be used to steal passwords from other users (think of CSRF, faked login screens etc.), which kinda defeats your next point:
Any functionality considered vulnerable to corruption (which means almost anything other than browsing the site), requires an account and login.

Let me back up a mo...

As far as system integrity and availability is concerned, I was thinking the approach I listed under point 1 in my previous reply (VM etc.) would be sufficient, on its own, for many useful projects.

This is a central issue. Do you think that the following can, at least in theory, work?

No logins; all data in the Parrodocs (and its underlying server) (potentially) public; all data (and code) in the Parrodocs (and its underlying server) open to temporary corruption or worse.

Stealers will eventually pass Parrodocs by because there's nothing worth stealing; no private data, and no worthwhile computation because mallory is more likely to be spotted on (and booted off of) a Parrodocs server than on a more conventional owned server.

(Vandals, otoh, might have a lot of fun.)

When trouble is spotted, a sysop or a bot either fixes the relevant page(s) or restarts the server and rolls all pages forward to the last known good set.

A login provides some value. It isn't about establishing trust and it won't even stop deliberate trouble makers, just as wikipedia's login feature doesn't, but it'll make a useful difference, I think.

if it's more like PHP than a wiki, where is the connection to

? :)

  • Comment on Re^4: RFC: self hosting Perl 6 string wiki

Replies are listed 'Best First'.
Re^5: RFC: self hosting Perl 6 string wiki
by moritz (Cardinal) on Sep 09, 2008 at 06:59 UTC
    I think I wasn't very clear on the attack vector I though about, let my try again.

    When you have the power of displaying arbitrary html/javascript/css on a page, you can fake everything, including a login form for others to use that actually sends their login/password to your private server.

    Which basically means that you can get login data without compromising the server in some way.

    Stealers will eventually pass Parrodocs by because there's nothing worth stealing;

    If you offer a service that you think is valuable or interesting, the "bad guys" will think the same. For example many people use the same password on different services, so snooping passwords has a value on its own.

    This is a central issue. Do you think that the following can, at least in theory, work?

    It can work, but only with the right attitude. When you think of it as a wiki which is rather open, I don't think it can. If you think of it as a CMS where only trusted persons get edit access, you might be more successful.

[reply]
      I think I wasn't very clear on the attack vector I though about, let my try again.
      I think you were already clear. I think I understand the issues you raise. Your latest elaboration did not further my understanding (or lack thereof).

      Which suggests I haven't been clear. So let me be as explicit as I can be: a core Parrodocs design philosopy is that all users are untrustworthy. In a direct analogy with wikipedia's content, none of which ought to be trusted, I don't think one can trust any of Parrodocs.

      If you offer a service that you think is valuable or interesting, the "bad guys" will think the same.
      And do what? Copy it? They're welcome. Share it? They're welcome. Abuse it? They're welcome, until we find the abuse, then we reboot. Every few minutes if need be.

      It can work, but only with the right attitude. When you think of it as a wiki which is rather open, I don't think it can. If you think of it as a CMS where only trusted persons get edit access, you might be more successful.

      This is the nub. I think some users will have the right attitude, others won't, and that that can still work.

      I've long thought wikipedia would succeed on some level even though many people continue to diss it as a pointless exercise, and many editors don't operate in the right spirit. I think the same thing can apply to a sort of codepedia, even if that means the box may need regular rebooting.

      Gotta run. Maybe the above concludes this thread anyway. Thanks for your feedback and any more you might have.

      love, raiph

[reply]

In Section Meditations