Re: [tw5] Re: I Think I Hacked TiddlyWiki

[Jeremy Ruston]

With a bit of creativity, practically anything is possible! You’re right in 
> that the JS could not have DIRECT access to the user’s file system, but as 
> explained in 
>
> https://nakedsecurity.sophos.com/2016/06/20/ransomware-thats-100-pure-javascript-no-download-required/,
>  
> one could simply use JS to connect to a server to install a malicious exe, 
> which it could then run. 
> Essentially, the JS could easily apply a cipher to the file to thus 
> “encrypt it”, and use the exe to rewrite the file content with this 
> encrypted text. 
> The exe could also handle deletion of backups, or pretty much anything 
> else needed. 
>

Hmm that article is about tricking users into double-clicking on .JS files 
so that they run under the Windows Scripting Host, and doesn't really cover 
the situation of TiddlyWiki.

Best wishes

Jeremy

 

>
> On Sat, Aug 21, 2021 at 7:02 PM Scott Simmons (Secret-HQ) <
> goo...@secret-hq.com> wrote:
>
>> On Tuesday, August 17, 2021 at 9:12:15 AM UTC-4 flanc...@gmail.com wrote:
>>
>> What makes this more dangerous than the iframe is that it has DIRECT 
>>> ACCESS to your TW instance, so practically anything can be done. For 
>>> example, I could steal your tiddlywiki instance, encrypt it, and hold it 
>>> for ransom, as soon as your page loaded.
>>>
>>
>> Just to make sure I'm understanding correctly:  That *particular* attack 
>> wouldn't yield much fruit, would it?  The attacker would have an encrypted 
>> version of TiddlyWiki only xe could access, but the original user would 
>> still have the version xe opened on xir local hard drive or the Web site xe 
>> loaded the page from in the first place.  All that would be encrypted for 
>> ransom would be the session-specific instance of that file, not the source 
>> file (which the browser can't encrypt and save over on the fly).
>>
>> Or am I misunderstanding?
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "TiddlyWiki" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to tiddlywiki+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/tiddlywiki/25edd7f6-9dcc-4109-8fb8-51884c6382acn%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/9f71bb5b-0882-41f5-ac01-b7e4305f0cb5n%40googlegroups.com.

Re: [tw5] Re: I Think I Hacked TiddlyWiki

[Scott Simmons (Secret-HQ)]

Super-interesting stuff!  Thanks for the background.

There's a bit of consolation in there, though:  It sounds like the RAA 
attack relies on getting the user to execute JS in the WSH rather than 
within the browser.  TiddlyWiki on Node or running through Bob.exe or in 
TiddlyDesktop *might* be a more vulnerable vector of infection than a 
TiddlyWiki running the latest version of a Chromium-based browser.  I'm not 
sure how those platforms compare to browsers when it comes to sandboxing 
the environment where scripts are executed.

The novel path of attack (sharing a .JS via tiddler with another TiddlyWiki 
user) is certainly worth considering as a potential vulnerability — but, as 
Tony said above, the balance between usability and security is often more 
nuanced than just locking down everything to prevent any possibility of 
infection.

This could be a great opportunity for some security-minded TiddlyWizards to 
come up with a script-vetting plugin to throw up red flags during the 
import of outside content.  Maybe there'd even be a way to leverage malware 
databases via API to keep it up to date on current threats.  That's all way 
above my head, though, and maybe be as great a can of worms as trying to 
lock down TiddlyWiki to protect it from rogue JS.

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/726eefec-7b61-4c24-91fd-194e7f40a312n%40googlegroups.com.

Re: [tw5] Re: I Think I Hacked TiddlyWiki

[Finn Lancaster]

@Scott,

With a bit of creativity, practically anything is possible! You’re right in
that the JS could not have DIRECT access to the user’s file system, but as
explained in
https://nakedsecurity.sophos.com/2016/06/20/ransomware-thats-100-pure-javascript-no-download-required/,
one could simply use JS to connect to a server to install a malicious exe,
which it could then run.
Essentially, the JS could easily apply a cipher to the file to thus
“encrypt it”, and use the exe to rewrite the file content with this
encrypted text.
The exe could also handle deletion of backups, or pretty much anything else
needed.

On Sat, Aug 21, 2021 at 7:02 PM Scott Simmons (Secret-HQ) <
goo...@secret-hq.com> wrote:

> On Tuesday, August 17, 2021 at 9:12:15 AM UTC-4 flanc...@gmail.com wrote:
>
> What makes this more dangerous than the iframe is that it has DIRECT
>> ACCESS to your TW instance, so practically anything can be done. For
>> example, I could steal your tiddlywiki instance, encrypt it, and hold it
>> for ransom, as soon as your page loaded.
>>
>
> Just to make sure I'm understanding correctly:  That *particular* attack
> wouldn't yield much fruit, would it?  The attacker would have an encrypted
> version of TiddlyWiki only xe could access, but the original user would
> still have the version xe opened on xir local hard drive or the Web site xe
> loaded the page from in the first place.  All that would be encrypted for
> ransom would be the session-specific instance of that file, not the source
> file (which the browser can't encrypt and save over on the fly).
>
> Or am I misunderstanding?
>
> --
> You received this message because you are subscribed to the Google Groups
> "TiddlyWiki" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to tiddlywiki+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/tiddlywiki/25edd7f6-9dcc-4109-8fb8-51884c6382acn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/CALXL%2BrPestGT_%3DGf4t_TvsNzoWCjh7PA9jzpsip96jObAAjY1g%40mail.gmail.com.

[tw5] Re: I Think I Hacked TiddlyWiki

[Scott Simmons (Secret-HQ)]

On Tuesday, August 17, 2021 at 9:12:15 AM UTC-4 flanc...@gmail.com wrote:

What makes this more dangerous than the iframe is that it has DIRECT ACCESS 
> to your TW instance, so practically anything can be done. For example, I 
> could steal your tiddlywiki instance, encrypt it, and hold it for ransom, 
> as soon as your page loaded.
>

Just to make sure I'm understanding correctly:  That *particular* attack 
wouldn't yield much fruit, would it?  The attacker would have an encrypted 
version of TiddlyWiki only xe could access, but the original user would 
still have the version xe opened on xir local hard drive or the Web site xe 
loaded the page from in the first place.  All that would be encrypted for 
ransom would be the session-specific instance of that file, not the source 
file (which the browser can't encrypt and save over on the fly).

Or am I misunderstanding?

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/25edd7f6-9dcc-4109-8fb8-51884c6382acn%40googlegroups.com.

[tw5] Re: I Think I Hacked TiddlyWiki

[TW Tones]

Thanks all for considering this;

I think the best way to limit risks is to provide plugins in trusted 
libraries, from trusted sources. then people could also install these in an 
empty html and run a vulnerability test using a plugin designed to 
highlight risks. As soon as a library contains something doggy the 
community can react.  

To facilitate this I would like an easy way to collect and publish a 
library from a single file wiki, then the well known and trusted people can 
publish libraries that they themself can check or anyone in the community. 
Libraries contain plugins frozen in a moment of time, Only libraries so 
tested would be listed publicly. With all other sources the designer can 
run a (latest) vulnerability test published on tiddlywiki.com and if we 
must we can blacklist or whitelist plugins or "signatures" in this 
vulnerability tester.

In another discussion I am also calling for a hash tool which although not 
invulnerable would add another layer of testing, mostly to see which system 
tiddlers have being modified, and this would just make cheating more 
difficult.

The power we have on our side is the community and the ability to collect 
and centralise data in a way that "outsiders" have more work to do before 
they can compromise anyone to a large extent, ie make it harder and cause 
diminishing returns. We can also ensure we have trusted sources and be able 
to test them. In this light we may even benefit from people hacking, 
because we can identify the vectors and respond.

But finally I want to reinforce in many wiki editions or personal on my 
desktop/mobile only, I do not want features crippled, diminished or 
destroyed for when the wiki may be placed on an internet facing editable 
platform. This is why I think the vulnerability test tool has the greatest 
value. Horses for courses.

Regards
Tones

On Thursday, 19 August 2021 at 08:55:14 UTC+10 joshua@gmail.com wrote:

> I agree that there are a lot of possible open "attack vectors", and 
> keeping track of every one is not feasable.
>
> Good conversation so far. I think the primarily concern is that TW will 
> run obfuscated javascript without a refresh required. That should have an 
> option to "Sandbox" that behaviour somehow, and let superusers unlock it.
>
> Thanks for the discussion!
>
> Best,
> Joshua Fontany
>
> On Wednesday, August 18, 2021 at 9:44:03 AM UTC-7 Mark S. wrote:
>
>> Really, it gets back to trust and reputation.
>>
>> A TW coder could write a tiddler that contains no javascript tiddlers, 
>> but that, when run, creates a javascript  tiddler that will later get run. 
>> So you would never see javascript code during import. The core TW is 
>> already pretty huge. Adding patch after patch for each imagined scenario 
>> eventually renders TW less and less useful.
>>
>> Also, it hasn't been demonstrated what harm could be done even if your 
>> standalone code was infiltrated. Could keystrokes be sent back to a server? 
>> Could file blocks be written anywhere other than the download directory? Of 
>> course on node or especially on any multi-user platform things become more 
>> hazardous.  In theory any server-based solution (e.g. node) could write to 
>> your file system and possibly invoke code. In practice, I found it very 
>> difficult to set up even when I wanted something like that.
>>
>>
>>  
>>
>>
>> On Wednesday, August 18, 2021 at 9:22:27 AM UTC-7 R² wrote:
>>
>>> Excellent points John. Most users will indeed not review the full text 
>>> of every single tiddler they import. I'm now thinking that pointing out 
>>> which ones should indeed be reviewed more explicitly would be both easy and 
>>> worthwhile.
>>>
>>> At the tm-import-tiddlers widget level, any JS that's being imported 
>>> could be flagged, with a simple highlight inviting the user to review the 
>>> code before confirming the import when standard declared JS is detected, 
>>> and a more insistent alert when the code is hidden or obfuscated (as in 
>>> Finn's Base64 example). A simple exhaustive filter search should be able to 
>>> cover all or most cases, including content-type=application/javascript, 
>>> 

[tw5] Re: I Think I Hacked TiddlyWiki

[Joshua Fontany]

I agree that there are a lot of possible open "attack vectors", and keeping 
track of every one is not feasable.

Good conversation so far. I think the primarily concern is that TW will run 
obfuscated javascript without a refresh required. That should have an 
option to "Sandbox" that behaviour somehow, and let superusers unlock it.

Thanks for the discussion!

Best,
Joshua Fontany

On Wednesday, August 18, 2021 at 9:44:03 AM UTC-7 Mark S. wrote:

> Really, it gets back to trust and reputation.
>
> A TW coder could write a tiddler that contains no javascript tiddlers, but 
> that, when run, creates a javascript  tiddler that will later get run. So 
> you would never see javascript code during import. The core TW is already 
> pretty huge. Adding patch after patch for each imagined scenario eventually 
> renders TW less and less useful.
>
> Also, it hasn't been demonstrated what harm could be done even if your 
> standalone code was infiltrated. Could keystrokes be sent back to a server? 
> Could file blocks be written anywhere other than the download directory? Of 
> course on node or especially on any multi-user platform things become more 
> hazardous.  In theory any server-based solution (e.g. node) could write to 
> your file system and possibly invoke code. In practice, I found it very 
> difficult to set up even when I wanted something like that.
>
>
>  
>
>
> On Wednesday, August 18, 2021 at 9:22:27 AM UTC-7 R² wrote:
>
>> Excellent points John. Most users will indeed not review the full text of 
>> every single tiddler they import. I'm now thinking that pointing out which 
>> ones should indeed be reviewed more explicitly would be both easy and 
>> worthwhile.
>>
>> At the tm-import-tiddlers widget level, any JS that's being imported 
>> could be flagged, with a simple highlight inviting the user to review the 
>> code before confirming the import when standard declared JS is detected, 
>> and a more insistent alert when the code is hidden or obfuscated (as in 
>> Finn's Base64 example). A simple exhaustive filter search should be able to 
>> cover all or most cases, including content-type=application/javascript, 
>> 

[tw5] Re: I Think I Hacked TiddlyWiki

['Mark S.' via TiddlyWiki]

Really, it gets back to trust and reputation.

A TW coder could write a tiddler that contains no javascript tiddlers, but 
that, when run, creates a javascript  tiddler that will later get run. So 
you would never see javascript code during import. The core TW is already 
pretty huge. Adding patch after patch for each imagined scenario eventually 
renders TW less and less useful.

Also, it hasn't been demonstrated what harm could be done even if your 
standalone code was infiltrated. Could keystrokes be sent back to a server? 
Could file blocks be written anywhere other than the download directory? Of 
course on node or especially on any multi-user platform things become more 
hazardous.  In theory any server-based solution (e.g. node) could write to 
your file system and possibly invoke code. In practice, I found it very 
difficult to set up even when I wanted something like that.


 


On Wednesday, August 18, 2021 at 9:22:27 AM UTC-7 R² wrote:

> Excellent points John. Most users will indeed not review the full text of 
> every single tiddler they import. I'm now thinking that pointing out which 
> ones should indeed be reviewed more explicitly would be both easy and 
> worthwhile.
>
> At the tm-import-tiddlers widget level, any JS that's being imported could 
> be flagged, with a simple highlight inviting the user to review the code 
> before confirming the import when standard declared JS is detected, and a 
> more insistent alert when the code is hidden or obfuscated (as in Finn's 
> Base64 example). A simple exhaustive filter search should be able to cover 
> all or most cases, including content-type=application/javascript, 

[tw5] Re: I Think I Hacked TiddlyWiki

['Mark S.' via TiddlyWiki]

I never got the alert. I'm curious why some people are reporting that it 
worked. Also, "alert" is very public and generally pretty harmless. 
Possibly it could be used as part of a phishing scheme.  It's not clear to 
me that you could create code that could modify anything outside the iframe 
sandbox. The suggestion was made that it could download something. Is there 
a demo for that?

On Wednesday, August 18, 2021 at 6:52:32 AM UTC-7 joh@gmail.com wrote:

> 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 

[tw5] Re: I Think I Hacked TiddlyWiki

[R²]

Excellent points John. Most users will indeed not review the full text of 
every single tiddler they import. I'm now thinking that pointing out which 
ones should indeed be reviewed more explicitly would be both easy and 
worthwhile.

At the tm-import-tiddlers widget level, any JS that's being imported could 
be flagged, with a simple highlight inviting the user to review the code 
before confirming the import when standard declared JS is detected, and a 
more insistent alert when the code is hidden or obfuscated (as in Finn's 
Base64 example). A simple exhaustive filter search should be able to cover 
all or most cases, including content-type=application/javascript, 

[tw5] Re: I Think I Hacked TiddlyWiki

[J. C. S.]

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 

[tw5] Re: I Think I Hacked TiddlyWiki

[TW Tones]

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 malicious javascript code, hidden 
>> in a data-uri to the server, which will sync it to all connected users is a 
>> concern...
>>
>> Best,
>> Joshua Fontany
>>
>> On Tuesday, August 17, 2021 at 10:12:13 AM UTC-7 TiddlyTweeter wrote:
>>
>>>  Mark S. wrote:
>>>
 That was one of the concerns with TWederation. You could import from 
 someone you trusted who imported from someone they trusted who ... 
 actually 
 couldn't be trusted. It's kind of a hard problem.

>>>
>>> *Right! *It IS an interesting issue. But *maybe as much an 
>>> anthropological issue as a technical one. *
>>> Suddenly tech switches into *"HOW CAN I TRUST?" *mode. 
>>> Despite the fact most everyone, well everyone, here (you, reading this) 
>>> is completely trust-worthy. 
>>> I think its a basic sociological fact that much of the internet is NOW 
>>> premised on the idea you can't trust anyone.
>>> It has led to a kind of "authentication gymnastics" that makes doing 
>>> some things very convoluted.
>>>
>>> Just rambles
>>> TT
>>>

 On Tuesday, August 17, 2021 at 8:13:42 AM UTC-7 saq.i...@gmail.com 
 wrote:

>
>> I'd be more concerned about people being tricked into importing a 
>> tiddler that contained code like this.
>>
>
> From my perspective this is the only practical concern, and once again 
> emphasizes the need to be careful when importing content from others. 
>


-- 
You received this message because you are subscribed to the Google Groups 

[tw5] Re: I Think I Hacked TiddlyWiki

['Mark S.' via TiddlyWiki]

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 malicious javascript code, hidden 
> in a data-uri to the server, which will sync it to all connected users is a 
> concern...
>
> Best,
> Joshua Fontany
>
> On Tuesday, August 17, 2021 at 10:12:13 AM UTC-7 TiddlyTweeter wrote:
>
>>  Mark S. wrote:
>>
>>> That was one of the concerns with TWederation. You could import from 
>>> someone you trusted who imported from someone they trusted who ... actually 
>>> couldn't be trusted. It's kind of a hard problem.
>>>
>>
>> *Right! *It IS an interesting issue. But *maybe as much an 
>> anthropological issue as a technical one. *
>> Suddenly tech switches into *"HOW CAN I TRUST?" *mode. 
>> Despite the fact most everyone, well everyone, here (you, reading this) 
>> is completely trust-worthy. 
>> I think its a basic sociological fact that much of the internet is NOW 
>> premised on the idea you can't trust anyone.
>> It has led to a kind of "authentication gymnastics" that makes doing some 
>> things very convoluted.
>>
>> Just rambles
>> TT
>>
>>>
>>> On Tuesday, August 17, 2021 at 8:13:42 AM UTC-7 saq.i...@gmail.com 
>>> wrote:
>>>

> I'd be more concerned about people being tricked into importing a 
> tiddler that contained code like this.
>

 From my perspective this is the only practical concern, and once again 
 emphasizes the need to be careful when importing content from others. 

>>>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/cd5627ea-860f-4609-a680-723a297a8b9dn%40googlegroups.com.

[tw5] Re: I Think I Hacked TiddlyWiki

[Joshua Fontany]

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 malicious javascript code, hidden in 
a data-uri to the server, which will sync it to all connected users is a 
concern...

Best,
Joshua Fontany

On Tuesday, August 17, 2021 at 10:12:13 AM UTC-7 TiddlyTweeter wrote:

>  Mark S. wrote:
>
>> That was one of the concerns with TWederation. You could import from 
>> someone you trusted who imported from someone they trusted who ... actually 
>> couldn't be trusted. It's kind of a hard problem.
>>
>
> *Right! *It IS an interesting issue. But *maybe as much an 
> anthropological issue as a technical one. *
> Suddenly tech switches into *"HOW CAN I TRUST?" *mode. 
> Despite the fact most everyone, well everyone, here (you, reading this) is 
> completely trust-worthy. 
> I think its a basic sociological fact that much of the internet is NOW 
> premised on the idea you can't trust anyone.
> It has led to a kind of "authentication gymnastics" that makes doing some 
> things very convoluted.
>
> Just rambles
> TT
>
>>
>> On Tuesday, August 17, 2021 at 8:13:42 AM UTC-7 saq.i...@gmail.com wrote:
>>
>>>
 I'd be more concerned about people being tricked into importing a 
 tiddler that contained code like this.

>>>
>>> From my perspective this is the only practical concern, and once again 
>>> emphasizes the need to be careful when importing content from others. 
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/cc9f0a92-b213-40eb-92fd-4dbf60246723n%40googlegroups.com.

[tw5] Re: I Think I Hacked TiddlyWiki

[TiddlyTweeter]

 Mark S. wrote:

> That was one of the concerns with TWederation. You could import from 
> someone you trusted who imported from someone they trusted who ... actually 
> couldn't be trusted. It's kind of a hard problem.
>

*Right! *It IS an interesting issue. But *maybe as much an anthropological 
issue as a technical one. *
Suddenly tech switches into *"HOW CAN I TRUST?" *mode. 
Despite the fact most everyone, well everyone, here (you, reading this) is 
completely trust-worthy. 
I think its a basic sociological fact that much of the internet is NOW 
premised on the idea you can't trust anyone.
It has led to a kind of "authentication gymnastics" that makes doing some 
things very convoluted.

Just rambles
TT

>
> On Tuesday, August 17, 2021 at 8:13:42 AM UTC-7 saq.i...@gmail.com wrote:
>
>>
>>> I'd be more concerned about people being tricked into importing a 
>>> tiddler that contained code like this.
>>>
>>
>> From my perspective this is the only practical concern, and once again 
>> emphasizes the need to be careful when importing content from others. 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/9535aff2-f31e-437c-b91d-6d0a6249fcb3n%40googlegroups.com.

[tw5] Re: I Think I Hacked TiddlyWiki

[TiddlyTweeter]

Mark S. wrote:

> ...  Modern browsers, as we have found out to our chagrin, tell you that 
> they are doing a download. They can only download to one place, which is 
> usually the download directory. They know nothing about the file system, 
> and can't even tell you the path of an image that has been loaded (also to 
> our chagrin). Once a file is downloaded, it can only be executed by a 
> deliberate action. On Linux, most file managers won't execute from the GUI 
> anymore, so no accidental clicking. On Windows, Windows pops up a message 
> warning you that you are about to run a potentially dangerous file. So it's 
> not easy to get your code executed even if it is downloaded.
>

Ciao Mark. I enjoyed this for both it's accuracy and it's acknowledgment of 
ongoing CHAGRIN. 

As it happens I am still on Timimi previous to latest on Firefox (i.e. the 
Saver & LAUNCHER) that lets you launch apps directly *(with a bit 
la-di-dah)* from TiddlyWiki. 

So, if *that* is insecurity, I'd like more of it. 

I think it insane to force web pages to be stupid when they can be really 
clever. 
TW, in particular, is really great when you also can control the computer 
from it.

Regarding the OP. The tech part of it is above my tech level, but I can't 
see any real issue that differs from the normal caveats about switching on 
a computer.

Best wishes
TT 

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/bf3ae51e-cae5-4f7f-bfbd-87a462b544c1n%40googlegroups.com.

[tw5] Re: I Think I Hacked TiddlyWiki

['Mark S.' via TiddlyWiki]

That was one of the concerns with TWederation. You could import from 
someone you trusted who imported from someone they trusted who ... actually 
couldn't be trusted. It's kind of a hard problem.

On Tuesday, August 17, 2021 at 8:13:42 AM UTC-7 saq.i...@gmail.com wrote:

>
>> I'd be more concerned about people being tricked into importing a tiddler 
>> that contained code like this.
>>
>
> From my perspective this is the only practical concern, and once again 
> emphasizes the need to be careful when importing content from others. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/49dafee4-2cd6-499f-a024-ea69b724098cn%40googlegroups.com.

[tw5] Re: I Think I Hacked TiddlyWiki

['Mark S.' via TiddlyWiki]

In my test, the code didn't do anything. So it's hard to evaluate. What 
exactly could the code do? Unless it could write to the file system (which 
is really hard in JS), or if it could send the keystrokes back to a 
server-based entity, it would not be able to accomplish anything. What 
browser are you testing with?

I think the WP article is talking about abilities that existed before 
modern browsers. Modern browsers, as we have found out to our chagrin, tell 
you that they are doing a download. They can only download to one place, 
which is usually the download directory. They know nothing about the file 
system, and can't even tell you the path of an image that has been loaded 
(also to our chagrin). Once a file is downloaded, it can only be executed 
by a deliberate action. On Linux, most file managers won't execute from the 
GUI anymore, so no accidental clicking. On Windows, Windows pops up a 
message warning you that you are about to run a potentially dangerous file. 
So it's not easy to get your code executed even if it is downloaded.

If a person deliberately puts code on their page that does malicious 
things, it doesn't matter how it is inserted. 

So basically, you're just saying that TW uses Javascript and somebody could 
insert additional JS. But that is a weakness/strength of all AJAX pages. 
It's not like I could go to an existing TW site and add my own malicious 
code. It would have to be running a special server based version of TW 
(node, Bob, ) to make that possible -- not the standalone.

In terms of self-protection, the best away to avoid malicious code would be 
to only use code/plugins that are WikiText based (after reviewing that it 
doesn't create JS tiddlers), or only using plugins from sources that you 
really, really trust (e.g. Eric S.)





On Tuesday, August 17, 2021 at 7:53:28 AM UTC-7 flanc...@gmail.com wrote:

> Mark, 
>
> The scenario I had in mind was: Person A (attacker), adds malicious code 
> to his TW instance, which is accessible via the web through GitHub pages, 
> or something similar. He then shares his wiki link with Person B, who 
> unknowingly goes to take a look at Person A's wiki. On doing this, Person B 
> then has this malicious JS execute on his end, thereby hacking/infecting 
> him.
>
> With JS, this exploit could be crafted in a variety of ways, as stated, 
> there is already pure-JS ransomware, which, combined with some creativity, 
> could trick the user into allowing the wiki to access the local filesystem. 
> There is also ways of installing damaging malware to the users system (see 
> https://en.wikipedia.org/wiki/Drive-by_download), purely from 
> vulnerabilities like this.
>
> So this exploit can reach beyond the scope of there being someone who "can 
> sit down at your desk and insert code."
>
> On Tuesday, August 17, 2021 at 10:30:02 AM UTC-4 Mark S. wrote:
>
>> I'm trying to understand what the problem is.
>>
>> TW isn't multi-user. If someone can sit down at your desk and insert 
>> code, then you already have security problems way beyond code.
>> Likewise, if you have a publicly exposed TW that anyone can save with, 
>> then you have security problems beyond a code hack.
>>
>> So I'm not seeing what the concern is. If someone has the ability to save 
>> to your TW, then you already have a security breach, regardless of the 
>> nature of the inserted code.
>>
>>
>> On Tuesday, August 17, 2021 at 7:21:56 AM UTC-7 R² wrote:
>>
>>> OK, got it to execute. For some mysterious reason, the first few 
>>> keypresses didn't do anything, then a few did, I clicked elsewhere and 
>>> modified another tiddler, the next few didn't, and when I went back to the 
>>> malicious tiddler to get it to execute again, it hadn't recorded keypresses 
>>> made in the other tiddler. It does seem as if it's at least partly 
>>> sandboxed but I'll defer to the core coders, I was just curious to see what 
>>> this was about.
>>>
>>> Best,
>>> R²
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/de43776c-b2b3-43ea-b96c-c793276bf3a1n%40googlegroups.com.

[tw5] Re: I Think I Hacked TiddlyWiki

[Saq Imtiaz]

>
>
> I'd be more concerned about people being tricked into importing a tiddler 
> that contained code like this.
>

>From my perspective this is the only practical concern, and once again 
emphasizes the need to be careful when importing content from others. 

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/373d5cfb-c7c8-490b-82a4-ca1bad623afan%40googlegroups.com.

[tw5] Re: I Think I Hacked TiddlyWiki

[Soren Bjornstad]

On Tuesday, August 17, 2021 at 9:53:28 AM UTC-5 flanc...@gmail.com wrote:

> Mark, 
>
> The scenario I had in mind was: Person A (attacker), adds malicious code 
> to his TW instance, which is accessible via the web through GitHub pages, 
> or something similar. He then shares his wiki link with Person B, who 
> unknowingly goes to take a look at Person A's wiki. On doing this, Person B 
> then has this malicious JS execute on his end, thereby hacking/infecting 
> him.
>

I'm still confused about this scenario. If we're not talking about 
inserting the code into someone else's wiki via XSS or something, how does 
TiddlyWiki allow anything here that an arbitrary website wouldn't? If a 
malicious user can post a page on the web and make the target go to it, 
then surely anything that a browser allows is fair game, and if there's 
fault here it should lie with the web browser, not TiddlyWiki. Because even 
if TW changed to disallow this, surely the malicious user could just revert 
that change in their own fork of TiddlyWiki and build their malicious wiki 
on that TW edition?

I'd be more concerned about people being tricked into importing a tiddler 
that contained code like this.

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/6b8a8e85-5545-4812-a266-b4fdffbe9937n%40googlegroups.com.

[tw5] Re: I Think I Hacked TiddlyWiki

[Finn Lancaster]

Mark, 

The scenario I had in mind was: Person A (attacker), adds malicious code to 
his TW instance, which is accessible via the web through GitHub pages, or 
something similar. He then shares his wiki link with Person B, who 
unknowingly goes to take a look at Person A's wiki. On doing this, Person B 
then has this malicious JS execute on his end, thereby hacking/infecting 
him.

With JS, this exploit could be crafted in a variety of ways, as stated, 
there is already pure-JS ransomware, which, combined with some creativity, 
could trick the user into allowing the wiki to access the local filesystem. 
There is also ways of installing damaging malware to the users system 
(see https://en.wikipedia.org/wiki/Drive-by_download), purely from 
vulnerabilities like this.

So this exploit can reach beyond the scope of there being someone who "can 
sit down at your desk and insert code."

On Tuesday, August 17, 2021 at 10:30:02 AM UTC-4 Mark S. wrote:

> I'm trying to understand what the problem is.
>
> TW isn't multi-user. If someone can sit down at your desk and insert code, 
> then you already have security problems way beyond code.
> Likewise, if you have a publicly exposed TW that anyone can save with, 
> then you have security problems beyond a code hack.
>
> So I'm not seeing what the concern is. If someone has the ability to save 
> to your TW, then you already have a security breach, regardless of the 
> nature of the inserted code.
>
>
> On Tuesday, August 17, 2021 at 7:21:56 AM UTC-7 R² wrote:
>
>> OK, got it to execute. For some mysterious reason, the first few 
>> keypresses didn't do anything, then a few did, I clicked elsewhere and 
>> modified another tiddler, the next few didn't, and when I went back to the 
>> malicious tiddler to get it to execute again, it hadn't recorded keypresses 
>> made in the other tiddler. It does seem as if it's at least partly 
>> sandboxed but I'll defer to the core coders, I was just curious to see what 
>> this was about.
>>
>> Best,
>> R²
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/7b9f49ee-8db5-42a1-a9e1-0789d54b01c8n%40googlegroups.com.

[tw5] Re: I Think I Hacked TiddlyWiki

['Mark S.' via TiddlyWiki]

I'm trying to understand what the problem is.

TW isn't multi-user. If someone can sit down at your desk and insert code, 
then you already have security problems way beyond code.
Likewise, if you have a publicly exposed TW that anyone can save with, then 
you have security problems beyond a code hack.

So I'm not seeing what the concern is. If someone has the ability to save 
to your TW, then you already have a security breach, regardless of the 
nature of the inserted code.


On Tuesday, August 17, 2021 at 7:21:56 AM UTC-7 R² wrote:

> OK, got it to execute. For some mysterious reason, the first few 
> keypresses didn't do anything, then a few did, I clicked elsewhere and 
> modified another tiddler, the next few didn't, and when I went back to the 
> malicious tiddler to get it to execute again, it hadn't recorded keypresses 
> made in the other tiddler. It does seem as if it's at least partly 
> sandboxed but I'll defer to the core coders, I was just curious to see what 
> this was about.
>
> Best,
> R²
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/2ad44e4a-e158-429d-ab8f-fac9cf905f89n%40googlegroups.com.

[tw5] Re: I Think I Hacked TiddlyWiki

[R²]

OK, got it to execute. For some mysterious reason, the first few keypresses 
didn't do anything, then a few did, I clicked elsewhere and modified 
another tiddler, the next few didn't, and when I went back to the malicious 
tiddler to get it to execute again, it hadn't recorded keypresses made in 
the other tiddler. It does seem as if it's at least partly sandboxed but 
I'll defer to the core coders, I was just curious to see what this was 
about.

Best,
R²

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/ee2f78bb-311f-4f27-9068-63060ac8c0b6n%40googlegroups.com.

[tw5] Re: I Think I Hacked TiddlyWiki

[Finn Lancaster]

@R2, the tiddler is blank by design. Once you have saved the tiddler, press 
a key on your keyboard, and it alerts the keynumber back to you. Typing 
multiple keys it will alert each key you've pressed as part of *every 
keypress*.

On Tuesday, August 17, 2021 at 9:47:27 AM UTC-4 R² wrote:

> Hi Finn,
>
> Could you perhaps post a video of what you see on your end? I tried on 
> several instances and don't get the "will alert your keystrokes back to 
> you" part, just a seemingly empty tiddler.
>
> Best,
> R²
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/4a26aef6-b48f-4961-ba82-fd628c6dfdf5n%40googlegroups.com.

[tw5] Re: I Think I Hacked TiddlyWiki

[R²]

Hi Finn,

Could you perhaps post a video of what you see on your end? I tried on 
several instances and don't get the "will alert your keystrokes back to 
you" part, just a seemingly empty tiddler.

Best,
R²

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/389517dd-4289-4d50-907f-f5402fc399dfn%40googlegroups.com.

[tw5] Re: I Think I Hacked TiddlyWiki

[Finn Lancaster]

Update: just let the devs know 
(https://github.com/Jermolene/TiddlyWiki5/issues/5960)

On Tuesday, August 17, 2021 at 9:12:15 AM UTC-4 Finn Lancaster wrote:

> Hello All,
>
> Following the discovery of the iframe content to execute JS in TiddlyWiki, 
> I began pentesting TW to find other methods of executing JS, but without 
> any kind of sandbox. What I discovered is that TW correctly sanitizes 
>