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
? :)
In reply to Re^4: RFC: self hosting Perl 6 string wiki
by Anonymous Monk
in thread RFC: self hosting Perl 6 string wiki
by raiph
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |