> I also think, that erics transclusions should be treated like plugins.
> And I also think, this can be achieved.
That's a good insight: what we're dealing with here is best treated as
a new kind of plugin, one that is evaluated at the point of reference,
rather than at startup. I really like that idea.
I'd think of it as a tiddler tagged "systemScript" that contains
javascript that is executed when the tiddler is referenced through
<<tiddler title>> (or perhaps some new syntax like [[[tiddler
title]]]). The JavaScript code would be invoked with the roughly same
context as macro handlers, plus the with: parameters on the
<<tiddler>> macro.
> 1) But "server side".
You're meaning that the verification for safety of systemScript
tiddlers would happen on the server? If so, I would agree.
> 2) As you can see that "not executing" evaluated parameters
> clientside doesn't add any security to tiddlyspace. As Tobias has
> shown with his quick eval hack.
Changing the implementation of evaluated parameters doesn't add
security on it's own, but it is one of the necessary components for us
to implement safe filtering on space inclusions in the future. Tobias'
quick eval hack is a systemConfig tiddler and so would be filtered out
of a safe inclusion. That's the whole point: forcing javascript code
up out of invisible {{blocks}} and into manageable plugins.
The motivation for bringing up the change early is to minimise
disruption; as the service grows, more spaces would be affected by any
change we make in the future.
> Some thoughts about 1)
> Hash the content, and compare against a "plugin whitelist", when the
> tiddler is saved.
> If it doesn't pass the test, it can be _private_ only.
> So I can use and test it until it passes the test.
That is also one of my motivations in being interested in the hashing
mechanism being added to the server.
> A private malicious tiddler can only effect space members. But as a
> owner of a space I'd only make someone a member, if I trust her or
> him. The server could tag a private tiddler "test not passed". So
> members can easily find them and togehter make them pass the "approved
> for public use" tests.
>
> There is the question. How to get a "plugin white listed"
> I think this should be discussed at TiddlyWeb or Dev group.
I was thinking of the hashing more for blacklisting plugins that have
known vulnerabilities. For example, a trusted member of the community
may write a plugin that unwittingly parses and processes some piece of
user input as HTML. Then, a mischievous person discovers that
vulnerability, and publishes a specially crafted tiddler that if
included in spaces that include the original plugin would cause data
loss. Note that the mischievous person there is only publishing "safe"
content, but is exploiting a flaw in trusted code. In that situation a
blacklist would be a good way to pick up people who have copied and
pasted the plugin into their spaces. I'm sure there are other measures
that need looking at too, but this fingerprinting seems pretty
fundamental.
In terms of whitelisting, I was thinking of letting users have a list
of spaces they trust, and optionally to also trust the spaces that
those spaces trust. Everyone would start by trusting tiddlyspace,
which would trust the established developers. As a user I would want
to know how many other people trust or actively mistrust a space.
As you say, the way that we establish all this deserves deep
discusion. It's possible that UnaMesa might have a role in this,
maintaining the register of the highest grade of trust for people who
have, say, been through a legal notarisation process so that the
community can have some confidence in who they are.
> ====
> There has been some dicussion about the target group, that uses/should
> use TiddlySpace.
>
> a) As a default user (80%) I'd want to write text.
> Make it public.
> Done.
>
> b) As an advanced user (15%) I'd want to write something like:
> <<tiddler {{tiddler.title + "_notes"}}>> or
> <<tiddler {{"[["+tiddler.title+"_notes]]"}}>>
> I think some server side white list filter can see that this should be
> allowed.
> Done.
You mean the whitelist filter combined with having the tiddler tagged
systemScript because it contains JavaScript?
> c) As a programmer (5%) I should be able to write code, that can be
> "approved for public use".
> And how to get "white listed" should imho be discussed at TiddlyWeb or
> TiddlyWikiDev group
Agreed, as above.
Cheers
Jeremy
> d) may be there is a better solution for b) so it can be added to a)
>
> -mario
>
> On Sep 22, 6:08 pm, Tobias Beer <[email protected]> wrote:
>> Hi Martin,
>>
>> I think Eric's transclusions provide awill fairly good benchmark as to
>> what others might as well (want to) accomplish and thus require
>> parameter evaluation.
>>
>> As I said, these transclusions essentially are like plugins and from
>> my point of view should be treated in the context of security measures
>> on TiddlySpace just like anything tagged systemConfig ...in the case
>> that parameter evaluation is being used in a transclusion.
>>
>> Cheers, Tobias.
>
> --
> You received this message because you are subscribed to the Google Groups
> "TiddlyWiki" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/tiddlywiki?hl=en.
>
>
--
Jeremy Ruston
mailto:[email protected]
http://www.tiddlywiki.com
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/tiddlywiki?hl=en.
