World: r3wp

Yes. But that is doing the *function*, not doing a word that refers 
to the function.

It's the difference between a: :print and a: 'print.

As said, all the respondents above prefer the function to be evaluated 
when doing a word that refers to the function. The only way how you 
can influence it would be if you said you preferred the current behaviour 
as implemented in R3. Do you?

For that, absolutely. For the lit-word/lit-path thing, no.

I hope we get more answers, since it is weekend now.

http://issue.cc/r3/1881and http://issue.cc/r3/1882submitted

Regarding the example evaluating words above:

    lit-path: first ['a(b]
    do [lype? lit-path]


Which result do you prefer? As far as my preferences go, I prefer 
to obtain the lit-path! datatype

Correction: Regarding the example evaluating words above:

    lit-path: first ['a/b]
    do [type? lit-path]


Which result do you prefer? As far as my preferences go, I prefer 
to obtain the lit-path! datatypeRegarding the example evaluating 
words above:

    lit-path: first ['a(b]
    do [lype? lit-path]


Which result do you prefer? As far as my preferences go, I prefer 
to obtain the lit-path! datatype lit-path: first ['a/b]
    do [lype? lit-path]

This keyboard is getting me crazy, sorry

Correction: Regarding the example evaluating words above:

    lit-path: first ['a/b]
    do [type? lit-path]


Which result do you prefer? As far as my preferences go, I prefer 
to obtain the lit-path! datatype

(in R3 yout get the lit-path!, while in R2 the path! datatype)

I prefer lit-path!. The same for lit-words:

	lit-word: first ['a]
	do [type? lit-word]


I prefer that to return lit-word!. It's only, if the word being looked 
up (lit-word in this example) is a function (or native, op, action, 
...) that further computation should occur, I think.

Makes sense

Actually I ran into problems related to this, when programming the 
bparse function. At one point, I need to test, if a token variable 
is equal to the word END. To specify the word END, I write it as 
a lit-word, because lit-words are changed to words on the run. I 
need to use == to compare, because I want the type to be the same 
too. So I would expect, this is the correct test:

	token == 'end

Let's test:

>> token: first [end]
== end
>> token == 'end
== true

Seems to work, but then the surprise, if token is a lit-word:

>> token: first ['end]
== 'end
>> token == 'end      
== true

Also true? Hmm, so I have to write:

>> :token == 'end
== false

The above is done in R2.

Strangely enough, with http://issue.cc/r3/1882you are proposing 
to do the opposite of http://issue.cc/r3/1881

In #1881 you are proposing to take what in R3 is currently an active 
value and render it inactive, which will make it mildly safer to 
handle - lit-word/lit-path conversion to word/path is a trivial thing. 
In #1882 you are proposing to make the word! type into an active 
value, where you would have to treat every word value as carefully 
as you treat the function it is assigned. Except it's worse, because 
in R2 it has the effect of doing *blocks* as well, if those blocks 
are assigned to a word - even DO of an inline word isn't that unsafe. 
It is really bad.

Please, be consistent here. If you accept #1881, please reject #1882, 
for our own safety.

Oh wait, I misread #1881, I thought it was the lit-path thing. Never 
mind, it's unsafe too.

I noticed when you did the poll, you used a safe function that you 
knew the source of. Do the poll again with a function that deletes 
your hard drive, or even a block of code for some other dialect that 
will coincidentally do damage when interpreted by the DO dialect 
(since R2 does this with blocks and parens as well). Or even a function 
that takes an unknown number of parameters, and put the call in the 
middle of code that might be affected by evaluation order or get-word 
hacking.

Most of you might not remember this, but parens used to be treated 
as active values in R2. If you had a paren assigned to a word, putting 
that word inline in a DO dialect block would cause the paren to be 
executed. I used to use this as a way of having quick thunks (functions 
that take no parameters) without calling DO explicitly. However, 
this made it difficult to work with paren values, and was eventually 
removed for security reasons because it made screening for potentially 
dangerous values more difficult than a simple ANY-FUNCTION? call. 
It would be bad to make word! and path! values just as difficult 
to work with.

In #1881 you are proposing to take what in R3 is currently an active 
value and render it inactive
 - do I?

No, I mistokk what you were saying, and corrected myself in the "Oh 
wait" message.

#1434, #1881 and #1882 now have clarifying comments.

Btw, this comment in #1882: "and since you've requested that lit-word! 
and lit-path! be returned to their R2-style inconsistency" may not 
be an accurate representation of your proposal (here earlier in conversation). 
You might be proposing that R3 do a better job at being inconsistent 
than R2 is doing (as demonstrated in #1434). If so, cool.

I prefer convenience, but understand the concerns about security. 
Less aggressive evaluation by DO doesn't solve the security problem 
though, does it? If we say "Never DO untrusted data", DO can provide 
more convenience. Of course, that means it may be less convenient 
if you have to evaluate untrusted data, but at least the line is 
clear.

>> o: make object! [f: does [42]]

>> do in o 'f		; This is a problem, as nothing seems to be happening!
>> o/f
== 42

I'm not sure, I understand the security concern.

Frankly, there is no security problem which can be influenced by 
this.

Stating otherwise is just pretending

If somebody wants to use DO, he is responsible for knowing what he 
is doing

Pretending that security doesn't matter is a worse policy. Here is 
what would resolve the security issue:

- Putting warnings in the docs for DO, in the same section where 
they talk about the special treatment of functions and blocks.

- Make parameters not work, and don't do blocks and parens through 
word values, same as R2's DO of path values.

- Make sute that we don't try to make set-words and set-paths do 
assignment when you DO them. Treat them like get-words and get-paths.


Together, those restrictions would make DO of word and path values 
no more insecure than DO of block and paren values. For functions, 
we have APPLY.

sute -> sure

btw, I've been using apply in R2.7.8 and it works really well   :-)

DO of block and paren values is something that we can say is secure 
enough already, assuming that variables and such are protected and 
secured, so that is a good set of restrictions to follow for words 
and paths. Calling functions through inline words is secure enough 
if you can control the binding and writeablility of those words. 
DO of function values has the argument problem, but it's known and 
has built-in workarounds (APPLY, putting function calls in parens), 
and we already have simple ways to screen for them.

DO is seductive, because sometimes I want to create (easily) a "dialect 
environment" and just use DO to evaluate my dialect., safely and 
securely. 


Is there a security page in the docs (I don't see one in the R3 docs 
right now)? If not, that would be good to have. If we have a list 
of functions and operations you shouldn't use on untrusted data, 
and what the risks are, that's a good start.

And, as Brian mentions, having workarounds or being able to screen 
for exploitable features.

I'd still like to see the sort of safe evaluation as dreamt of in 
this older ML thread:
    http://www.rebol.org/ml-display-thread.r?m=rmlNVBC

There isn't much of a security page right now, though it would be 
a good idea to make one if only to document the stuff that doesn't 
currently work (like SECURE in the last 4 versions). I don't know 
if anyone else has made a concerted effort to attack REBOL and then 
fix the security problems found.

I would love it if we as a community were to really think through 
the (UN)PROTECT model, because the current model is incomplete (even 
for the stuff that works) and the proposed model is starting to look 
a bit awkward to use. Keep in mind that PROTECT may also be used 
to make series sharable among tasks, but that this isn't implemented 
and there is likely a better way to do this. I would love it if there 
was a good security model that can integrate well with REBOL semantics.

Capabilities

Won't work within a process, only on a process boundary.

Depends on if you make it work

It's inherent in the semantics of REBOL, a side effect of the code-vs-data 
thing.

Do you know the Genode architecture?

That might work for SECURE but not for (UN)PROTECT.

Why not?

(I am trying to write a long *starting* message here and have to 
put it in the clipboard to answer these questions, sorry.)

That's OK, I'm interested in your opinion. I haven't formulated an 
answer for myself yet

Some factors to consider about the REBOL semantic limitations:


- There is no such thing as trusted-vs-untrusted code in a REBOL 
process, nor can there be, really. Levels of trust need to be on 
a process boundary. You can't (even hypothetically) do LOAD/secure 
level or DO/secure level, but you can do LAUNCH/secure level.


- If you want to make something readable or writeable to only certain 
code within a process, binding visibility tricks are the only way 
to do it. The only way to ensure that your code has access to something 
and other code doesn't is to make sure that other code can't even 
see yours. This is why BODY-OF function returns an unbound copy of 
the body in R3, not the original.


- We need a way to make protection stick so you can't unprotect things 
that are protected, or protect things that need to stay unprotected, 
but still allow changes to the protection status of other stuff. 
The currently proposed model does this through a chain of PROTECT 
and UNPROTECT calls, then a PROTECT/lock, not allowing unlocking 
if there is a SECURE 'protect. However, the proposed model seems 
too difficult to use, and as the pre-110 module system demonstrated, 
people won't use something that is too complex to use, or will use 
it badly. We need a better way of specifying this stuff.

OK, that's the current REBOL model, but you asked about alternative 
models. Capabilities are not about trust levels, but about capability 
tokens. They're meant to take trust out of the equation