Unsafe file variables...

Unsafe file variables...

[David Kastrup]

Ok, I have had an idea which might be stupid or not.  And it might
also have political implications which I am too stupid to see.  I just
want to put it out.

Emacs warns about potentially unsafe file variables and stuff, like

;;; Local variables:
;;; eval: (put 'preview-defmacro 'lisp-indent-function 'defun)
;;; end:

Now it is a nuisance to get this question each time, and it is not
feasible to disable the question permanently due to security reasons.

How about the following then?

;;; Local variables:
;;; eval: (put 'preview-defmacro 'lisp-indent-function 'defun)
;;; end:
;;; gpg-signed: iD8DBQFAbwnJBo350SLJfmgRAhf9AKCFvutpMNxc4oGK/vh2fdVV0MT/dgCeJn66
;;; Qc8BXtn2zlGbofY2YMLIAg8=
;;; =s5sr

Something like that.  I would then customize a variable that tells
whose signatures I trust enough not to get the stupid question again
and again.

Obviously, this also makes it possible for me to look at the local
variable block once, decide that it is good enough for me, and sign
it.

Any change in local variables will render the signature invalid, of
course.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Unsafe file variables...

[Richard Stallman]

    Something like that.  I would then customize a variable that tells
    whose signatures I trust enough not to get the stupid question again
    and again.

    Obviously, this also makes it possible for me to look at the local
    variable block once, decide that it is good enough for me, and sign
    it.

It looks good to me, but it would be good to get comments
from security experts.

Re: Unsafe file variables...

[Stefan Monnier]

>     Something like that.  I would then customize a variable that tells
>     whose signatures I trust enough not to get the stupid question again
>     and again.

>     Obviously, this also makes it possible for me to look at the local
>     variable block once, decide that it is good enough for me, and sign
>     it.

> It looks good to me, but it would be good to get comments
> from security experts.

The feature is fine, though any security expert will at the very least hold
his judgment until he sees the code.


        Stefan

Re: Unsafe file variables...

[Stefan Monnier]

>     Something like that.  I would then customize a variable that tells
>     whose signatures I trust enough not to get the stupid question again
>     and again.

>     Obviously, this also makes it possible for me to look at the local
>     variable block once, decide that it is good enough for me, and sign
>     it.

> It looks good to me, but it would be good to get comments
> from security experts.

I think that using authentication for such problems is the wrong approach.
We should check the safety of the code instead.  Think of it as "check
whether a piece of code is signed" (the Microsoft notion of security) vs
"check that the code type checks" (the Java notion of security).

Now in general it's clearly impossible to check any arbitrary piece of
elisp code and give a good answer.  But a good solution was proposed
a while back here: add a customization variable that allows the user to
specify a list of safe code which he's willing to eval in the future.


        Stefan

Re: Unsafe file variables...

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> >     Something like that.  I would then customize a variable that tells
> >     whose signatures I trust enough not to get the stupid question again
> >     and again.
> 
> >     Obviously, this also makes it possible for me to look at the local
> >     variable block once, decide that it is good enough for me, and sign
> >     it.
> 
> > It looks good to me, but it would be good to get comments
> > from security experts.
> 
> I think that using authentication for such problems is the wrong
> approach.  We should check the safety of the code instead.

That implies that only one approach was possible.  I was not talking
about discouraging checking for safety: signatures should only be a
fallback when the safety is not possible to check.  And of course the
user will be free not to accept any signatures and will lose nothing
over the current situation.

> Think of it as "check whether a piece of code is signed" (the
> Microsoft notion of security) vs "check that the code type checks"
> (the Java notion of security).

Well, we already have determined that the variable _is_ unsafe to
set.  But since there still is an imaginable reason for setting that
variable, the user gets the question.  If you think that you can rule
out the desirability of not mechanically checkable code being run,
then that is the obvious way to go.  But I don't see any sandbox
model for Elisp that would get us even half there.

> Now in general it's clearly impossible to check any arbitrary piece
> of elisp code and give a good answer.  But a good solution was
> proposed a while back here: add a customization variable that allows
> the user to specify a list of safe code which he's willing to eval
> in the future.

The list would have to get added to for each change.  In short, the
user would have to manually judge the potential of the danger of such
settings for each change, and record his decision.  I was proposing a
mechanism allowing delegation of such decisions to a verified source
the user has declared trustworthy.

This is less safe than a qualified judgment of the user for himself
for every instance.  _IF_ the user is capable of making a qualified
judgment.  If he has to depend on others for it, a way to let him
make sure that he at least knows reliably _who_ he is trusting to
might not be amiss.

Again: I was not certain about how good or feasible this proposal is,
and I am also not sure whether it would not better be solved as an
integral part of some scheme dealing with more than local variables.

I just noticed that I get frequently annoyed by such questions and was
trying to come up with a comparatively safe way to avoid them.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Unsafe file variables...

[Stefan Monnier]

>> Think of it as "check whether a piece of code is signed" (the
>> Microsoft notion of security) vs "check that the code type checks"
>> (the Java notion of security).

> Well, we already have determined that the variable _is_ unsafe to set.

No, we have only determined that the variable is not always safe to set.
That's very different.

> But since there still is an imaginable reason for setting that
> variable, the user gets the question.  If you think that you can rule
> out the desirability of not mechanically checkable code being run,
> then that is the obvious way to go.  But I don't see any sandbox
> model for Elisp that would get us even half there.

I don't understand what you're trying to say.

>> Now in general it's clearly impossible to check any arbitrary piece
>> of elisp code and give a good answer.  But a good solution was
>> proposed a while back here: add a customization variable that allows
>> the user to specify a list of safe code which he's willing to eval
>> in the future.
> The list would have to get added to for each change.

Yes.  Just like it would have to be re-signed for each change.

> In short, the user would have to manually judge the potential of the
> danger of such settings for each change, and record his decision.

Exactly.  Just as is the case right now, except that he would get to record
his decision so he won't be prompted over and over again in the future.

> I was proposing a mechanism allowing delegation of such decisions to
> a verified source the user has declared trustworthy.

Yes, that's what I understood and what I consider as undesirable.

> This is less safe than a qualified judgment of the user for himself
> for every instance.  _IF_ the user is capable of making a qualified
> judgment.

The same "IF the user is capable of making a qualified judgment" applies to
the authentication approach: the user has to assess the trustworthiness of
the source instead of the safety of the code.

Accepting a key does not just mean "I trust that Foo never intends harm",
but rather "I trust that every person who will ever get access to Foo's
private key will never intend harm".

> I just noticed that I get frequently annoyed by such questions and was
> trying to come up with a comparatively safe way to avoid them.

My approach is much more lightweight and can probably be coded in 10 lines.
I do believe in the "philosophical" arguments above, but ultimately the
implementation simplicity is what I'd aim for.


        Stefan

Re: Unsafe file variables...

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> Ok, I have had an idea which might be stupid or not.  And it might
> also have political implications which I am too stupid to see.  I just
> want to put it out.
> 
> Emacs warns about potentially unsafe file variables and stuff, like
> 
> ;;; Local variables:
> ;;; eval: (put 'preview-defmacro 'lisp-indent-function 'defun)
> ;;; end:
> 
> Now it is a nuisance to get this question each time, and it is not
> feasible to disable the question permanently due to security reasons.

There is already a simple solution to this in CVS emacs:

Just add it to safe-local-eval-forms (e.g. via customize).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Unsafe file variables...

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> >> Think of it as "check whether a piece of code is signed" (the
> >> Microsoft notion of security) vs "check that the code type checks"
> >> (the Java notion of security).
> 
> > Well, we already have determined that the variable _is_ unsafe to
> > set.
> 
> No, we have only determined that the variable is not always safe to
> set.  That's very different.

In each particular case where we would want to consult a signature, we
have determined that we don't know whether setting the variable could
be dangerous.  That means we have determined that it is unsafe to
set.  That's the premise.  We would not be in the situation to pop up
a question if that was not the case.  The signature is not
interesting for any other case.

> > But since there still is an imaginable reason for setting that
> > variable, the user gets the question.  If you think that you can
> > rule out the desirability of not mechanically checkable code being
> > run, then that is the obvious way to go.  But I don't see any
> > sandbox model for Elisp that would get us even half there.
> 
> I don't understand what you're trying to say.

That the safeness of setting an Elisp variable can't be always
decided automatically and by the computer just by looking at the
code.  In the end, someone will have to look at the code and decide
whether it is safe.  This will be the responsibility of the user.
Now he may have a list as follows:

1. Emacs says setting the variable that way is safe.

The user probably trusts Emacs enough to not bother further.  He can
set his variables to express this belief.

2. Whoever put that stuff in the file probably feels this is safe.

That says pretty much nothing.  Who was it?  Probably many persons.

3. The file claims that Stefan Monnier says this is safe.

Well, if malicious code was in there, it would probably claim
whatever it wanted.

4. Stefan Monnier has checked the setting, declared it as safe and
   signed it.

Now the user has the choice to configure _once_ "if it's good enough
for Stefan Monnier, it is good enough for me."

And he can be reasonably sure that indeed Stefan Monnier and not
somebody else has checked this setting and declared it safe.

> >> Now in general it's clearly impossible to check any arbitrary
> >> piece of elisp code and give a good answer.  But a good solution
> >> was proposed a while back here: add a customization variable that
> >> allows the user to specify a list of safe code which he's willing
> >> to eval in the future.

> > The list would have to get added to
> > for each change.
> 
> Yes.  Just like it would have to be re-signed for each change.

No.  Each change that would trigger such a message needs to be signed.
But if I told my system once "If Stefan Monnier has signed a change,
don't ask", then while you need to sign each such change you do, but a
hundred users need to tell their Emacs only once that they trust your
judgment.

> > In short, the user would have to manually judge the potential of
> > the danger of such settings for each change, and record his
> > decision.
> 
> Exactly.

You are confusing the scenarios.  This sentence is for the case
without signatures.  It is the case I want to avoid.

> Just as is the case right now, except that he would get to record
> his decision so he won't be prompted over and over again in the
> future.

Well, it would be nice if I could decide "don't prompt me
particularly for every change Stefan Monnier makes".

If I decide that I don't want to trust Stefan Monnier blindly,
deciding whether to answer such a prompt might benefit from the
information "My GPG system says that this change, purported to be
called safe from Stefan Monnier, indeed has been called safe by him".

> > I was proposing a mechanism allowing delegation of such decisions
> > to a verified source the user has declared trustworthy.
> 
> Yes, that's what I understood and what I consider as undesirable.

Well, if that's what you understood, I can't follow your reasoning.
And I fail to see where you explain why it would be undesirable.
When I put forward this proposal, I already said that there might be
good reasons against it.  I just fail to see what you would consider
a good reason.

> > This is less safe than a qualified judgment of the user for
> > himself for every instance.  _IF_ the user is capable of making a
> > qualified judgment.
> 
> The same "IF the user is capable of making a qualified judgment"
> applies to the authentication approach: the user has to assess the
> trustworthiness of the source instead of the safety of the code.

Right.  But he has to do this only once, not every time.  And for
many persons, trusting a person is an easier decision than trusting
their judgment about a particular piece of potentially malicious code.

> Accepting a key does not just mean "I trust that Foo never intends
> harm", but rather "I trust that every person who will ever get
> access to Foo's private key will never intend harm".

Right.  It trusts the person's judgment in his key management as well.

> > I just noticed that I get frequently annoyed by such questions and
> > was trying to come up with a comparatively safe way to avoid them.
> 
> My approach is much more lightweight and can probably be coded in 10
> lines.  I do believe in the "philosophical" arguments above, but
> ultimately the implementation simplicity is what I'd aim for.

But your approach does not allow to factor "xxx has declared this
change safe" into either the user's or Emacs' decision.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Unsafe file variables...

[Kim F. Storm]

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> writes:
> 
> > Ok, I have had an idea which might be stupid or not.  And it might
> > also have political implications which I am too stupid to see.  I just
> > want to put it out.
> > 
> > Emacs warns about potentially unsafe file variables and stuff, like
> > 
> > ;;; Local variables:
> > ;;; eval: (put 'preview-defmacro 'lisp-indent-function 'defun)
> > ;;; end:
> > 
> > Now it is a nuisance to get this question each time, and it is not
> > feasible to disable the question permanently due to security reasons.
> 
> There is already a simple solution to this in CVS emacs:
> 
> Just add it to safe-local-eval-forms (e.g. via customize).

I just checked that this _is_ documented in NEWS, but it is also
marked so that is NOT added to the emacs manual (---).

IMO, this is a very useful feature which should not be hidden to users.

What about adding this to custom.texi:

*** custom.texi	02 Nov 2003 08:01:02 +0100	1.60
--- custom.texi	05 Apr 2004 04:23:05 +0200	
***************
*** 1060,1065 ****
--- 1060,1071 ----
  neither @code{t} nor @code{nil}, so normally Emacs does ask for
  confirmation about file settings for these variables.
  
+ @findex safe-local-eval-forms
+   The @code{safe-local-eval-forms} is a customizable list of eval
+ forms which are safe to eval, so Emacs should not ask for
+ confirmation to evaluate these forms, even if
+ @code{enable-local-variables} says to ask for confirmation in general.
+ 
  @node Key Bindings
  @section Customizing Key Bindings
  @cindex key bindings


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Unsafe file variables...

[Stefan Monnier]

>> >> Think of it as "check whether a piece of code is signed" (the
>> >> Microsoft notion of security) vs "check that the code type checks"
>> >> (the Java notion of security).
>> > Well, we already have determined that the variable _is_ unsafe to
>> > set.
>> No, we have only determined that the variable is not always safe to
>> set.  That's very different.
> In each particular case where we would want to consult a signature, we
> have determined that we don't know whether setting the variable could
> be dangerous.

OK, whatever: we agree.

>> >> Now in general it's clearly impossible to check any arbitrary
>> >> piece of elisp code and give a good answer.  But a good solution
>> >> was proposed a while back here: add a customization variable that
>> >> allows the user to specify a list of safe code which he's willing
>> >> to eval in the future.
>> > The list would have to get added to
>> > for each change.
>> Yes.  Just like it would have to be re-signed for each change.

> No.  Each change that would trigger such a message needs to be signed.
> But if I told my system once "If Stefan Monnier has signed a change,
> don't ask", then while you need to sign each such change you do, but a
> hundred users need to tell their Emacs only once that they trust your
> judgment.

Hmmm... I guess you're considering a very different usage pattern
from mine.  In my estimate of how things play out in practice, there is
the following:
1 - "usafe file vars" are not very frequent.
2 - they're not very varied either (because you'll open the same file many
    times, because the same setting will be used in several files, because
    it's used for things tat don't change much, ...).
3 - they're mostly used "by the author, for the author".
4 - they'll be signed by the author of the file in 99% of the cases.

>> > In short, the user would have to manually judge the potential of
>> > the danger of such settings for each change, and record his
>> > decision.
>> Exactly.
> You are confusing the scenarios.  This sentence is for the case
> without signatures.  It is the case I want to avoid.

For the case with signature, the author (which I expect to be the main user)
will have to do it, just the same.

> Well, it would be nice if I could decide "don't prompt me
> particularly for every change Stefan Monnier makes".

The problem is:
- are there going to be more pieces of code or more authors?
  You assume there'll be many more different pieces of code than authors,
  whereas I expect that there'll be about as many of each.

> If I decide that I don't want to trust Stefan Monnier blindly,
> deciding whether to answer such a prompt might benefit from the
> information "My GPG system says that this change, purported to be
> called safe from Stefan Monnier, indeed has been called safe by him".

Sure.

> When I put forward this proposal, I already said that there might be
> good reasons against it.  I just fail to see what you would consider
> a good reason.

I'm not opposing it, but I just don't think it's worth the trouble.
I think that `safe-local-eval-forms' (which I didn't notice had been
installed: cool) covers the need just fine for now (after all, we've had
always/never/prompt as the only method until very recently and I haven't
seen too many people complain).
I'd personally be interested as well in improving the automatic safety
checking so that prompting (and safe-local-eval-forms or sign-checking)
is needed less often.  But I've seen so few concrete and useful examples
of local vars, that it's difficult to know what to look at.

>> > This is less safe than a qualified judgment of the user for
>> > himself for every instance.  _IF_ the user is capable of making a
>> > qualified judgment.
>> 
>> The same "IF the user is capable of making a qualified judgment"
>> applies to the authentication approach: the user has to assess the
>> trustworthiness of the source instead of the safety of the code.

> Right.  But he has to do this only once, not every time.

As mentioned above, I don't expect this to be very different in practice,
because most users will typically only ever get one piece of code to check
from any given author.  So they'll spend their time downloading public keys
and blessing them as trusted.  The scheme would maybe work of we could have
delegation such that RMS could bless your key as trustworthy and users
wouldn't have to, but that gets even more Big-Brotherish.

> And for many persons, trusting a person is an easier decision than
> trusting their judgment about a particular piece of potentially
> malicious code.

Easier maybe.  Better, I don't know.

>> Accepting a key does not just mean "I trust that Foo never intends
>> harm", but rather "I trust that every person who will ever get
>> access to Foo's private key will never intend harm".
> Right.  It trusts the person's judgment in his key management as well.

And in his behavior in case of threats, depression, whatever.

>> > I just noticed that I get frequently annoyed by such questions and
>> > was trying to come up with a comparatively safe way to avoid them.
>> 
>> My approach is much more lightweight and can probably be coded in 10
>> lines.  I do believe in the "philosophical" arguments above, but
>> ultimately the implementation simplicity is what I'd aim for.

> But your approach does not allow to factor "xxx has declared this
> change safe" into either the user's or Emacs' decision.

Indeed.  Feel free to submit a patch.  And explain the kind of scenarios
you're imagining where a given author will write many such pieces of "unafe
file vars" and many users will want to use them.
Note that as a package author you are already trusted: you can create
a foo-mode function in AUCTeX and then just add a `mode: foo' entry
that will call the function, assuming it to be safe.


        Stefan

Re: Unsafe file variables...

[Richard Stallman]

    I think that using authentication for such problems is the wrong approach.
    We should check the safety of the code instead.

There is a package whose job is to check an expression for safety.
I installed it last year, but I don't recall the file name.

Of course, it is conservative--there are many programs which are
safe, but it can't tell, so it says "no".  That being so, I am not
sure whether this approach will do a good job in practice.

      But a good solution was proposed
    a while back here: add a customization variable that allows the user to
    specify a list of safe code which he's willing to eval in the future.

Perhaps the two features can be combined.
That package could treat anything it finds in that list as "safe".

Re: Unsafe file variables...

[Eli Zaretskii]

> From: storm@cua.dk (Kim F. Storm)
> Date: 05 Apr 2004 04:25:47 +0200
> > 
> > There is already a simple solution to this in CVS emacs:
> > 
> > Just add it to safe-local-eval-forms (e.g. via customize).
> 
> I just checked that this _is_ documented in NEWS, but it is also
> marked so that is NOT added to the emacs manual (---).

"---" means that this _should_not_ be in the manual, not that it
wasn't yet added.

It's possible that this was done on purpose, I don't know.

Re: Unsafe file variables...

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

[...]

> > No.  Each change that would trigger such a message needs to be signed.
> > But if I told my system once "If Stefan Monnier has signed a change,
> > don't ask", then while you need to sign each such change you do, but a
> > hundred users need to tell their Emacs only once that they trust your
> > judgment.
> 
> Hmmm... I guess you're considering a very different usage pattern
> from mine.

Apparently.

> In my estimate of how things play out in practice, there is the
> following: 1 - "usafe file vars" are not very frequent.  2 - they're
> not very varied either (because you'll open the same file many
> times, because the same setting will be used in several files,
> because it's used for things tat don't change much, ...).

Point 1 and 2 might change in future, particularly when file contents
become "more active".  At the current point of time, it would
probably be more relevant for the user if complete Elisp files were
signed, but this is something that can be solved outside of Emacs as
long as Emacs itself does not fetch and install packages.

But when we are talking about things like texts with file variables,
or C (instead of Lisp) code with file variables and so on, and we are
talking about people working with CVS, then it becomes inconvenient if
the whole file has to be signed when the security relevant part is
just the file variable block: whenever somebody (or yourself) changes
a file, the respective signature would get invalid, even though the
safety relevant part for editing (as opposed to executing) would be
just in the file variables.

> 3 - they're mostly used "by the author, for the author".
> 4 - they'll be signed by the author of the file in 99% of the cases.

I was thinking of something different, obviously.  When we are
working on Elisp files in CVS, there will be many more people looking
at a file than just the author.

> > You are confusing the scenarios.  This sentence is for the case
> > without signatures.  It is the case I want to avoid.
> 
> For the case with signature, the author (which I expect to be the
> main user) will have to do it, just the same.

Taking Emacs code as an example: do you really think that the author
of each piece of code can be called its main user?  I should hope
that more people than just the author get to use and even view a
particular code piece.

> The problem is:
> - are there going to be more pieces of code or more authors?
>   You assume there'll be many more different pieces of code than authors,
>   whereas I expect that there'll be about as many of each.

We'll see how this pans out in future.  I was not proposing this as
something that is dearly necessary right now.

> I'm not opposing it, but I just don't think it's worth the trouble.

Currently: yes.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Unsafe file variables...

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>       But a good solution was proposed
>     a while back here: add a customization variable that allows the user to
>     specify a list of safe code which he's willing to eval in the future.
> 
> Perhaps the two features can be combined.
> That package could treat anything it finds in that list as "safe".

It's already there -- safe-local-eval-forms.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Unsafe file variables...

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>       But a good solution was proposed
>     a while back here: add a customization variable that allows the user to
>     specify a list of safe code which he's willing to eval in the future.
> 
> Perhaps the two features can be combined.
> That package could treat anything it finds in that list as "safe".

It occurred to me that we could improve the use of safe-local-eval-forms
by allowing the user to answer the question "eval local form: xxx" in
such a way that the form is automatically added to safe-local-eval-forms.

E.g. (y)es (n)o (p)erm.

That would be much simpler than the complex functionality suggested by David.

But we may also want to save a negative response, so maybe we should add
unsafe-local-eval-forms and have these options:

(y)es (n)o (Y)es (N)o

where the latter two add the form to either safe-local-eval-forms or
unsafe-local-eval-forms.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Unsafe file variables...

[Kim F. Storm]

"Eli Zaretskii" <eliz@gnu.org> writes:

> > From: storm@cua.dk (Kim F. Storm)
> > Date: 05 Apr 2004 04:25:47 +0200
> > > 
> > > There is already a simple solution to this in CVS emacs:
> > > 
> > > Just add it to safe-local-eval-forms (e.g. via customize).
> > 
> > I just checked that this _is_ documented in NEWS, but it is also
> > marked so that is NOT added to the emacs manual (---).
> 
> "---" means that this _should_not_ be in the manual, not that it
> wasn't yet added.

That's what I meant -- somebody decided this was not sufficiently
useful for users to know about.  I disagree.

> 
> It's possible that this was done on purpose, I don't know.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Unsafe file variables...

[Richard Stallman]

    It occurred to me that we could improve the use of safe-local-eval-forms
    by allowing the user to answer the question "eval local form: xxx" in
    such a way that the form is automatically added to safe-local-eval-forms.

    E.g. (y)es (n)o (p)erm.

I think people would often say yes without really thinking.

Re: Unsafe file variables...

[Kevin Rodgers]

Richard Stallman wrote:

>     It occurred to me that we could improve the use of safe-local-eval-forms
>     by allowing the user to answer the question "eval local form: xxx" in
>     such a way that the form is automatically added to safe-local-eval-forms.
> 
>     E.g. (y)es (n)o (p)erm.
> 
> I think people would often say yes without really thinking.

Until they got tired of answering the same question the same way, and noticed
that there are other valid responses.

-- 
Kevin Rodgers