Well, what I see is this:
If you use TW, you use JavaScript. And if you use JavaScript code from
unknown / unsafe sources, you will run the risk of the code doing things
that it shouldn't be doing. That should actually be clear to everyone. But
that's not a problem for TW, but in principle for every website that takes
full advantage of the possibilities of HTML5. And at last, it's the problem
of all data: You have to trust in it.
A particular security problem of TW is, of course, that TW has all the
tools to integrate new (dangerous) code in the simplest possible way,
without the user always being aware of what he is doing. The special thing
about it is not only that it is so easy to do. It is also particularly
difficult to understand and keep track of, because the file is constantly
being changed and saved.
Of course, you can take the trouble to review the code you are adopting and
also ensure that no one else can insert their own code. But honestly, who
does it? We usually trust what we find - at least on the sites we know. And
what we are inserting is not always obvious. The example code above, for
example. In plain language it reads:
var keylog = [];
document.addEventListener('keyup', function(e){
keylog.push(e.which);
alert(keylog);
});
Which of you deciphered it before trying it out?
TW Tones schrieb am Mittwoch, 18. August 2021 um 08:12:13 UTC+2:
> Mark et al
>
> You said *TW wasn't built from the ground-up for mult-user, and it's
> definitely not how most people are using it. I'm sure products built as
> server-side entities (e.g. WikiMedia) have all sorts of protection against
> injected code. *
>
> I agree, yet we have Bob which makes this plausible at least where people
> who access the wiki are trusted such as in a team. Perhaps not secure on
> the internet where anyone can get to it.
>
>- I think this may be a self fulfilling prophesy, we don't have secure
>methods to share online or run in a multi-user mode, so no one does.
>- Because we don't have multi-user solutions on the internet people
>come to expect all the control they want on their own local wikis, I don't
>want the security tail wagging the dog, if I want to iframe sites I use,
> or
>use it to drag and drop patches between wikis, I would not like this being
>locked down.
>- Despite me calling for this mulit-user functionality, see Check in
>and out critical to the use of tiddlywiki #5919
> with the
>simplest form serial editing using a check out and in facility I can't
> seem
>to get any traction on this.
>
> Given the discussion in this thread, perhaps we need a way to harden
> tiddlywiki for the internet, but I hope we don't harden it for the sole or
> LAN users or teams. It seems we may need to "bifurcate" to the risky and
> less risky environments, another possibility is being able to run a
> vulnerability check on a wiki.
>
> The best security will give us our cake and we can eat it too, the wrong
> security will mean we can't eat the cake, or look at it in the security of
> our own room.
>
> In closing of great importance are the many possible ways tiddlywiki can
> be made use of, but we need to maintain flexibility even when attempting to
> secure it the the "great unwashed internet", because it often has little or
> nothing to do with the internet.
>
> Regards
> Tones
>
>
>
> On Wednesday, 18 August 2021 at 13:33:11 UTC+10 Mark S. wrote:
>
>> TW wasn't built from the ground-up for mult-user, and it's definitely not
>> how most people are using it. I'm sure products built as server-side
>> entities (e.g. WikiMedia) have all sorts of protection against injected
>> code.
>>
>> Anyone who can write and save a tiddler can make a javascript tiddler,
>> or a widget, or overwrite a javascript filte operator, or maybe header
>> scripts, or maybe in-frame code. I guess you would have to think of all the
>> ways that code could be injected and then neutralize everything that
>> matched. But you'd have to do it before the tiddlers got written to the
>> common pool, and you'd have to either block legitimate uses of the iframe,
>> or figure out some way to detect that the frame doesn't contain js source
>> code.
>>
>>
>>
>> On Tuesday, August 17, 2021 at 7:06:05 PM UTC-7 joshua@gmail.com
>> wrote:
>>
>>> I am currently playing with "real-time multiplayer" capabilities for
>>> TW5, so this is an interesting security vulnerability to be aware of.
>>>
>>> My primary concern was "what if a malicious user connected a
>>> MIS-IDENTIFIED wiki to a real-time server. It has a bunch of malicious
>>> tiddlers, and it DOES NOT have a bunch of tiddlers that exist in the server
>>> copy."
>>>
>>> The real-time sync, once authenticated and authorized, would just
>>> absoloutely wreck the server-copy of the wiki in this instance.
>>>
>>> Similarly, being able to some-how sync
