[texworks] Scripting read access

[Paul A Norman]

Hi,

I think it is great that people who know what they are doing can make
the various choices you have presented, it is really good.

But I don't believe they really provide any sort of real protection in
the sense that once the box is ticked. that's the end of the matter -
no real on-going security considerations are being made by the User at
all, they may even forget they turned something on over the months
ahead..

(I have canvassed the following some months ago---apologies if you
remember) What about having all scripts turned off by default in the
Script Manager until the User turns each one on (and the setting is
then remembered for future sessions of Tw)?

The facility is already built in.

Is  just now everything is ticked "on" by default, that is where I
actually see a malicious script being able to do harm if it can some
how actually get into the script folder or a sub directory. When
scripts are reloaded and at Tw startup up all new scripts in the
script folder and subdirectories are automatically turned on at
present?
So if system/ or plug-ins, or write/ have been previously enabled, now
a malicious script that has mysteriously positioned itself could run
with no further permissions.

If scripts found during start-up or script reload,  were instead "off"
by default unless the user has previously turned them "on", wouldn't
that give us a higher level of security than a one time decision to
turn a whole potentially dangerous feature on. for all scripts, for
all time?

Could we additionally even simply scan a script when the user clicks
to turn it "on" in Script manager, and if certain tokens/key words or
certain script file extensions are  found, the user is advised/warned
what the potential issues are in turning that script on?

Stefan I believe you are right about the generalised differences noted
by many between Windows and other OS Users, and so feel we need to
either go simplistic (Master Switch), or do really real measures
because of this lack of understanding and experience amongst a great
bulk of Windows users.

Tick boxes for Read/Write/System and plug-ins as only oncer decisions,
in my view only provide a false sense of security - you and Jonathan
have already very neatly built Script by script management - tick "on"
or "off", into the Script Management dialogue, so why don't we
leverage it to full measure?

It simply becomse a necesary step in installing a script, reload
scripts, then  go to script manager and turn it on.

Could I also please request that script readFile  (and even writeFile)
 be available by default for the whole script folder and
subdirectories to facilitate libraries and saving global
configurations?
Or a script accessible dedicated script-library folder, and
script-data folder, please?

Paul



>> Here I am assuming that scripts get into the Tw/config/scripts folder
>> because the user is placing them there.  If we imagine that rogue
>> scripts are going to find their way to that folder in a malicious
>> manner, then what safety or purpose is there in ever ticking the
>> security relax tick boxes?



On 6 December 2010 20:08, Stefan Löffler <st.loeffler at gmail.com> wrote:
> Hi,
>
> On 2010-12-05 23:15, Paul A Norman wrote:
>> I still feel that emphasizing inspection, and the provenance of
>> scripts, is the best protection people have -
>>
>>  where did they get the script from?
>>  do they have reason to trust the script writer?
>>  Have they read though it?
>>  does it use the system or  writeFile etc  words
>>   - what does it use such words to do?
>
> Agreed. Though the last two points are probably beyond the average
> script-user (i.e., non-author). This will certainly be emphasized in the
> manual.
>
>> Even a non-scripter could spot such words, and if they didn't look
>> 'right in their use'  ask a question on a forum first - and perhaps be
>> introduced to scripting through the process.
>
> Asking on a forum or the mailing list sounds like a good idea.
>
>> Otherwise in a sense, what is a user deciding when they simply turn on:
>>   allow scripts to read files,
>>   allow scripts to write files,
>>   allow system commands,
>> or use powerful script plugins.
>>
>> What is the average Tw user actually, in reality, basing these decisions on?
>
> I guess this is more of a question of philosophy. On Linux, for example,
> most everyone is familiar with the rwx permissions. On Windows,
> permissions are not generally so well-known, or if they are, they are
> perceived only as an annoyance (and requires to rerun the command as
> administrator without much further thinking).
>
> Anyway, I'd expect most (simple) scripts to require no special
> permissions, since they can read document-related files. It's probably
> only a handful of power-scripts that need more advanced features. And in
> that case, the security permissions could also be seen as an incentive
> for script authors to think over if they really need this or that
> permission, and if they do, this requires some form of documentation
> (which is good in itself ;)). If some (most?) users just blindly follow
> what they are told without thinking, then so be it. But others may know
> something about permissions, or about plugins, and they might want a
> more fine-grained control.
>
> So, what I'm saying is this: if users need to enable something anyway,
> it doesn't matter so much if this is a single master switch or if they
> have to click two or three checkboxes. But it can make a huge difference
> for people who know about this stuff... And I would rather not let users
> enable formatting of the hard disk if they just want to use a script
> that reads a file...
>
>> Here I am assuming that scripts get into the Tw/config/scripts folder
>> because the user is placing them there.  If we imagine that rogue
>> scripts are going to find their way to that folder in a malicious
>> manner, then what safety or purpose is there in ever ticking the
>> security relax tick boxes?
>
> I hope it never comes to this (that rogue scripts get there), but it
> can't be ruled out. So ultimately, this is a decision between security
> and freedom in functionality (as it always is). By default, nothing is
> relaxed, so you have full security - and this should be feasible for
> many users (in particular those who do not use scripting regularly or at
> all). If you need more power, you need to relax the security measures,
> but whether or not you do this is up to you as user. I don't think we
> (the developers) should make this decision for all users out there. And
> if you do relax the security measures, you should be aware of the
> possible consequences, and might also want to better guard/check your
> scripts folder, etc.
>
>> Thinking about it in those terms led me to think that we were perhaps
>> being developer centric in the security issues - and that in its
>> present form and genesis, some of it will make no, or little, sense at
>> all to many of the kind of new TeXworks users we want to attract into
>> using LaTeX.
>>
>> That's why I gravitated into thinking about some sort of Master
>> Switch, and be done with it.
>
> As above: this is a question of philosophy, rather than a question of
> developer vs. user. On Linux, for example, everyone has to deal with
> permissions fairly often. This may not be the case on Windows (which I
> think is a bad thing, but that's beside the point).
> Anyway, "simple" scripts will work without any changed settings. More
> powerful features will require the user to read and follow the
> documentation of the script. I don't see too much of a problem in there.
> But the user interface is not carved in stone ;).
>
> Cheers,
> Stefan
>