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

Hey Moritz,

Thanks for the feedback. Any more greatly appreciated.

> Security:

  1. Parrodocs will run in a VM (eg openVZ). It will be possible to quickly restore a Parrodocs to a known "good" point. Data that must be any or all of persistent, secret, or ACIDly written, lives on a different server (eg an Amazon one).
  2. Any functionality considered vulnerable to corruption (which means almost anything other than browsing the site), requires an account and login.
(Due to the many misunderstandings I've read online over the years, I hesitate to mention Safe.pm -- "a failed experiment" -- and I wish to emphasize that use of such a module is not part of my plans at this point. That said, I still expect a useful Parrot version of Safe to be written within the next couple years and I would expect it to be useful in Parrodocs.)

> Usefulness: why the heck do you need to run arbitrary code on a wiki page?

Well, as another approximation, Parrodocs isn't really a wiki, it's sort of like a PHP (done right). (But please remember, this is again an approximation; please don't respond with "I hate PHP", because Parrodocs is really a squeakish Perl6/website IDE. Well, actually it's a platform for experimenting with non-linear communication. Well ... urgh. Part of the point of this meditation was to work out which part of the elephant to describe first next time I try.)

> Maintainability: There's a reason why code and templates are usually separated, and that is maintenance.

Newbies don't care about maintenance, and they'll be delighted that they can just write "Hello $mom" and it'll DWIM. In contrast, an advanced developer might want total separation -- perhaps an XML + XSLT solution. I think Parrodocs will cover both extremes and variants in between.

I look forward to any further thoughts from my fellow Monks...

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

Replies are listed 'Best First'.
Re^3: RFC: self hosting Perl 6 string wiki
by moritz (Cardinal) on Sep 08, 2008 at 22:23 UTC
    Parrodocs will run in a VM (eg openVZ). It will be possible to quickly restore a Parrodocs to a known "good" point. Data that must be any or all of persistent, secret, or ACIDly written, lives on a different server (eg an Amazon one).
    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.
    If you can steal account data by manipulating everything that's visible on the page, accounts loose their value.
    Well, as another approximation, Parrodocs isn't really a wiki, it's sort of like a PHP (done right)

    I'm happier with that description. But if it's more like PHP than a wiki, where is the connection to (update: ... november)

[reply]
      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

      ? :)

[reply]
        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]

In Section Meditations