Re: [cowiki-dev] Extension to coWiki text formatting

You know, I was sure I spell checked this before I sent it!  :-/

PAUL HANCHETT wrote:

> Archie Campbell wrote:
>
>> PAUL HANCHETT wrote:
>>
>>> Archie Campbell wrote:
>>>
>>>>
>>>> I really don't know about the extent to which 'availability of 
>>>> [sophisticated formatting] will be controlled by the site 
>>>> administrator', but I would like to comment briefly on the proposed 
>>>> markup, mostly the stuff that is already familiar.
>>>
>>> This is a security feature that we'd need to add on the 
>>> administration pages.  Basically the ability to turn the processing 
>>> that enables these features on and off.
>>
>> Why don't we need this already?
>
> Because we don't allow "html" or anything "dangerous".  One of the 
> arguments against just passing through anything that looks like html 
> and "Devil take the hindmost" has been concerns bout hijacking the 
> browser. 
>
>>>> Does coWiki attempt to save & redisplay? Certainly stuff that can't 
>>>> be processed is often displayed in full, a sort of 'default to 
>>>> verbatim'. If we can define parser-success, then we can 
>>>> fail-to-verbatim. What if closing all tags was all we had to put 
>>>> faith in?
>>>
>>> Presently coWiki will save text that it does not recognize as 
>>> valid.  dtg must have included a mechanism to make this happen 
>>> because I see it.  What I'm proposing is to make the parser robust 
>>> enough to detect when text is poorly formatted.  Since the text that 
>>> the user submitted will still be available, it can be returned to 
>>> the user for correction, along with hints about where the problem is.
>>
>> Like any parser, coWiki will be able to guess, often poorly, what the 
>> user is getting at. The desired intelligence behind the parser's 
>> comments won't be cheap to provide. I can only think of holding 
>> unrecognised tags up for examination, and pinpointing problems with 
>> the emphatic markup (single asterisks occurring). However, if 
>> desired, the parser's witty comments will be as much a problem as 
>> bona fide misparsing.
>
> The real point isn't guessing what the user is getting at, it's 
> determining that the document is well formatted.  The problem right 
> now is that coWiki has to store the misformatted document in order to 
> let the user re-edit it.  If we require that documents be correct to 
> be stored, we can promise that they will at least get their original 
> text back (which doesn't always happen now!)
>
>>>> LPIs...
>>>>
>>>> May be found at newline, also must be first element (provided by 
>>>> initial parse if not submitted).
>>>
>>> LPI's can occur anywhere.  This is necessary so that elements from 
>>> one language can be included in another.  For example, to include a 
>>> coWiki constant into an HTML page.  It has the same purpose as 
>>> scripting in HTML and JSP.
>>
>> So LPIs won't be an attempt to provide html-embedded foreach and 
>> other control loop behaviour. That's too difficult to imagine and 
>> needed a virtual machine. More like, LPIs provide access (secured) to 
>> variables at point. That way we won't need to parse to an in-core 
>> parsed representation, and can go straight to pretty xml.
>
> Right... Though it is worth noting that the text of the page just gets 
> inserted onto the TPL document for display, the the TPL itself is 
> being interpreted by the template processor.  From the template you 
> can certianly invoke PHP, and from PHP you can invoke anything 
> available on the server-- right?  ;-)
>
>>>> Only cowiki and html (pasted verbatim) a present. Awaiting 
>>>> security. How do we secure raw php? Or is what is wanted more a 
>>>> syntax highlighter like GeSHi?
>>>
>>> ACK.  I don't see PHP or any other language as crucial at the 
>>> moment.  I more wanted to demonstrate how they fit into the whole 
>>> picture, to understand that language selection operates at a higher 
>>> level than the current language selection.  (I think that's the key 
>>> to making it simple to implement.)
>>
>> I'm imagining that still means GeSHi is more likely than rules for 
>> securing inline php.
>
> Not sure what GeSHi is.  No one in their right mind will give general 
> users the right to use PHP.  But there may be some legitimate user for 
> it by a trusted "power" user.  It doesn't see reasonable to get 
> wrapped around the post over a feature only a select few *should* ever 
> use.  :-)
>
>>> ---
>>>
>>> On the issue of language security-- There are natural and self 
>>> consistent extensions following these rules:
>>>
>>>     * The ability to save pages with a language feature represented
>>>       either by a group or can be assigned to groups by the site
>>>       administrator.  (Only one of these is required, and
>>>       representing a feature by a single group is probably both
>>>       easier to implement and faster to execute.)
>>>
>> Feature by single group has my vote.
>
> ACK.  Mine too.
>
>>>     * A user is given the ability to save pages which invoke a
>>>       certain language feature by adding that langugage group to
>>>       their group list.
>>>
>> Ditto.
>>
>>>     * A user will not be allowed to save a page that invokes a
>>>       language feature they are not entitled to use.
>>>
>> The entire textarea is returned to them, with another box showing 
>> line-before, line & line-after the forbidden area, or something?
>
> Over-all, I hate XP.  But this is a place where the mantra "Do the 
> simplest thing" works.  They get all the text and maybe a warning that 
> it includes a feature they aren't allowed to save.  So a user can make 
> a page "less" risky by removing features they aren't allowed to save, 
> but they can't make it more risky.  They also can't change the context 
> of a feature by changing its surroundings (although I can't see where 
> that would be a risk).
>
> Basically the worst they could do is to deface a page, accidentally or 
> intentionally.  And we face *that* risk for any page they can edit anyway.
>
>>>     * To prevent a "got-you" syndrome, a user should be prohibited
>>>       or at least warned when they attempt to edit a page that uses
>>>       a feature they are not entitled to.  (Maybe just warned
>>>       because they may be removing the feature...)
>>>
>> I'm still thinking this is better limited to plugins. Maybe they can 
>> edit (for interest's sake), but the xml is plugged with a dummy-tag 
>> for the forbidden feature.
>
> Well, then the problem becomes that you need to start applying 
> security to plugins.  Which /plugins/ is the user allowed to add to 
> the page?  The functionality of the /embed/ plugin is limited to 
> images and flash.  I assume that it's not the more general embedded 
> object for just this reason.
>
>>>     * Individual language features can be turned on and off by the
>>>       site administrator.  If a feature is turned off, it cannot be
>>>       parsed on a page when it is saved. 
>>>
>>> All of this security intentionally pertains to pages when they are 
>>> /saved/.  This lets previously saved pages, which invoke now 
>>> disabled features, to continue to work without error.
>>
>> No reason why it couldn't appertain to previous pages now in xml format.
>
> "Pertain", right?  :-)  It could pertain, except that these extended 
> constructs aren't presently recognized by the output processing of coWiki.
>
>>
>> You know, I'd feel a deal better if the markup was available to all, 
>> but some of those kinky, specialised plugins were locked-down and 
>> reserved for special occasions. Otherwise, I'm not sure that 
>> page-saving is the right time for security. It may even be healthy to 
>> provide a dummy tag for markup-that-is-forbidden, allowing 
>> differential viewing to win out, where frustrated editing is more 
>> like a teething error.
>
> NACK.  It could of course be done, but the overhead is serious.  It's 
> like letting the enemy walk amongst you and issueing amored vehicles 
> and bullet proof vests to the citizenry.  Easier to stop the bad guys 
> at the border!
>
>>
>> coWiki is, of course, the security-conscious wiki, but Paul has 
>> really surprised me with his totalitarian vision! While it will be 
>> far simpler to cut things out of a fully-working parser, I support 
>> discussion to improve our understandings of each others' 
>> conceptualisations.
>
> :-)  Why, Thank You, Archie!  You say such nice things!  <G>  I'm 
> really trying to answer objections raised by others when I asked to be 
> able to include general HTML markup on a page!  I think in most real 
> situations these features would be totally on or off for the content 
> generating people.
>
>>
>> Isn't it only foolproof security when the plugin or markup is refused 
>> during rendering? Isn't there the possibility of man in the middle 
>> until that point?
>
> If you're not on a secure connection, there's *always* a possibility 
> of a man in the middle!  But you're right-- Someone could make an 
> entry directly into the coWiki database.  We do rely on the security 
> of the database.
>
> The other hole is a time-bomb--  A privileged user creates a malicious 
> page and they are then demoted to a lesser level.  Their malicious 
> page still exists and won't be caught on display.
>
> The concern I have is this:  It's important that pages display 
> quickly.  This means rendering times have to be kept low.  To check 
> security at display time would likely mean checking each XML tag, or 
> maybe having a digest of tags used on the page (which would then be 
> subject to man in the middle type attacks).
>
> When the page is parsed for saving, we can affort to take a second or 
> two for this to happen.  That same second or two at display time is an 
> eternity.
>
> Further, at display time, who are you checking security relative to?  
> The page owner, the owning group, the person viewing the page?  The 
> last person to edit it, or everyone who's saved the page?
>
> I think the key is /who do you trust to change the content of the 
> page/, and you only know that at save time.
>
> :-)
>
> Paul
>