//steve.

I feel for you and the "two contradictory beliefs simultaneously".

Just keep in mind, With a read only html file served to the world the 
content visible or not, can be found, its content is not protected in 
anyway. But of course the server is protected unless contained therein your 
html file is compromising information. Just make it clear to users their 
TiddlyWiki is globally accessible and an open book. Include nothing you do 
not want the world to see.

The ability to use tiddlywiki in the browser unsaved to disk, or saved 
locally is fabulous for user interaction because they can enter their own 
custom data. This will be extended somewhat with the pending release of the 
next version that includes a local storage plugin, the thing to do is 
reassure security this is local browser storage, not on the server 
(Although it will look like it).

Further, If you permit people to publish to the server, or do it on their 
behalf, make it clear in the domain / folder names this is demo or student 
published content. Otherwise they could construct a "trojan" wiki that 
looks like an official site and miss represents the colledge.

In future the local storage plugin could be used to install a trojan on one 
computer only, although look as if it were only the wiki stored at a 
readonly html address. But once again give a meaning full  domain / folder 
name and they can't conceal it completely.

Regards
Tony

On Friday, February 22, 2019 at 5:11:34 AM UTC+11, st...@sunypoly.edu wrote:
>
> Thank for the responses...I think I've got it (and this confirms my 
> understanding): so I'll try to summarize:
>
> As Eric notes, as long as there are no server-side scripts, TiddlyWiki is 
> just like any other HTML file, and the fact that visitors can modify 
> **their** local "copy" of the wikii in their browser has no impact on my 
> server. As long as they don't have write permissions -- thus, we should (as 
> I've proposed) do our wiki development in a secure sandbox, and wiki 
> serving on the public Web site. And, to repeat, just be sure I've got it: 
> there is nothing different (from a security perspective) about an html that 
> happens to be a tiddlywiki and an html file generated by drupal or any 
> other content management system.
>
> As Lost Admin (?) notes, correctly, that giving individuals *edit* privs 
> in a TiddlyWiki is a whole different ballgame -- and that is not what I'm 
> asking for.
>
> Many thanks for the insights. It's interesting trying to convince info 
> tech professionals to hold two contradictory beliefs simultaneously:  that 
> TW is really not much different than any other html files you've seen, and 
> that TW is radically different than every other application you've ever 
> seen.
>
> //steve.
>
>
> On Thursday, February 21, 2019 at 10:17:03 AM UTC-5, Lost Admin wrote:
>>
>> Hi Steve,
>>
>> On the topic of your first point, TiddlySpot PHP... TiddlySpot uses a 
>> program on the server to save the Tiddlywiki file. When you press the save 
>> button on your tiddlywiki, it makes a call to the server side program to 
>> save itself on the server.
>>
>> The team is saying they need to review the server side script, apparently 
>> written in PHP. I reviewed a variation of that script. In my opinion the 
>> version I reviewed is adequate for a hobby site. I would want a lot of 
>> enhancements to it for anything serious (but that's just my opinion).
>>
>> On the second point, there are really 2 issues in the one point. 
>>
>> First is that anyone with access to save a tiddlywiki on your site could 
>> modify the javascript that makes tiddlywiki work. Since tiddlywiki is 
>> giving you the ability to edit the javascript within the tiddlywiki, it is 
>> easy for anyone who has access to it to modify and save it so that it 
>> affects the next person to view the tiddlywiki.
>>
>> Second is the issue of cross-site-scripting (XSS). That is, because the 
>> core of tiddlywiki can be modified by anyone who can save a tiddlywiki, 
>> they can have it call outside scripts (this is how things like the discus 
>> plugin work). The problem is, like the first part, once one person modifies 
>> it, it is affected by everyone else who uses the tiddlywiki.
>>
>> In summary, tiddlywiki requires a very high level of trust in everyone 
>> who can edit a tiddlywiki document. As such, it may not be appropriate for 
>> environments where you shouldn't place a high level of trust in your users. 
>> Like say the students at a University.
>>
>> The node.js version of Tiddlywiki might be a bit better in addressing the 
>> above, but it would still need to prevent the users from saving any 
>> javascript.
>>
>> On Thursday, February 21, 2019 at 9:47:20 AM UTC-5, st...@sunypoly.edu 
>> wrote:
>>>
>>> Hello old friends,
>>>
>>> I'm working with the CIO at my University to see if it is possible to 
>>> serve tiddlywiki files on our Web site.
>>>
>>> These are two concerns that have been raised:
>>>
>>>
>>>    - Adding the TiddlySpot PHP script to enable rewriting from the 
>>>    browser is a potential security vulnerability that needs to be 
>>> thoroughly 
>>>    vetted by the web team. 
>>>    - Exposing core JS files that can be publicly edited and have 
>>>    changes applied from the browser is a potential XSS vulnerability.
>>>
>>>
>>> Not sure what the first means ("TiddlySpot PHP" script  - I had sent him 
>>> a wiki served on TiddlySpot as an example of a page I wanted to host on our 
>>> site). Could I eliminate that by building wikis from scratch on the 
>>> desktop, or using TiddlyDesktop, or even on google drive?
>>>
>>> The second - any thoughts? Can changes to the JS be applied from the 
>>> browser? 
>>>
>>> (Is this question better asked in the TiddlyWiki dev group 
>>> <https://groups.google.com/forum/#!searchin/TiddlyWikiDev/xss%7Csort:date> 
>>> -- a place I've always feared entering... :)?
>>>
>>> Thanks for your help!
>>>
>>> //steve.
>>>
>>>
>>>

-- 
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 post to this group, send email to tiddlywiki@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/74aa0530-73e5-4fa5-b18f-3804e74b97d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to