Re^5: RFC: self hosting Perl 6 string wiki

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.

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

Replies are listed 'Best First'.
Re^6: RFC: self hosting Perl 6 string wiki by raiph (Deacon) on Sep 09, 2008 at 17:28 UTC
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]

Replies are listed 'Best First'.

Re^6: RFC: self hosting Perl 6 string wiki
by raiph (Deacon) on Sep 09, 2008 at 17:28 UTC

I think I wasn't very clear on the attack vector I though about, let my try again.

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.

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]