Re: Emacs in a Corporate Environment

[Marcin Borkowski <mbork@mbork.pl>]

On 2023-04-13, at 02:08, Corwin Brust <corwin@bru.st> wrote:

> It sounds like the main concerns here are in the general area of
> "information leakage". It may be helpful to understand that this is

Which is a /very/ valid concern.

> also a major concern for GNU (and an important area of focus for the
> Free Software Society in terms of our guiding philosophies).
>
> No part of Emacs (including org) comes set up to send information to
> other systems beyond the host on which Emacs is running. Especially,

Except, obviously, packages whose goal is specifically that (TRAMP).  Of
course, it is still safe in the sense that TRAMP does not "call home",
only to the server you explicitly ask it to call to.

> Emacs is NOT equipped to connect to/with "Software as a Service"
> providers, to which GNU/FSF are categorically opposed.
>
> Responding point-by-point to the mentioned capabilities:
> - auto-complete provided with Emacs does not use resources external to
> Emacs; it is limited to scanning the files/projects being editing,
> their "CTAGS", etc.
> - suggested text is possible to configure, using the same (local to
> the machine running Emacs) functionality as for auto-complete
> - NO optical character recognition or other image recognition included
> - Image processing is limited to
>    - displaying
>    - scaling
>    - rotating
>    - cropping, and
>    - playing multi-frame (animated) images
>    - Emacs also provides image creation primitives; It is possible
> (although a bit painful, perhaps) to use Emacs as a drawing tool

Ha, I'm doing it right now in some code I'm working on.  And I can agree
-- it is possible, and a bit painful indeed. ;-)

> - NO text-to-speech is provided with Emacs
> - NO search engines are integrated with Emacs

Let's slow down here -- doesn't eww try duckduckgo by default?

> - Emacs does not have any virtual assistant (nothing AI/ML driven
> whatsoever is integrated with Emacs)

Well, I would argue that Emacs /is/ one of the best "virtual assistants"
in existence.  Of course, this is 99.99% not what is meant by that
document.

>> I guess I am a little new to this process, so I might be overreacting.
>> I just want to make sure that Emacs isn't taken away.

Totally understood!  Not having Emacs at work would be /terrible/.

>> This is a little embarrassing, but I hope this can help someone else
>> avoid being in the same situation.
>>
>> Best Regards,
>>
>> Yuan
>
> Hopefully, others will answer and/or help corroborate (or refine) my
> answers.  Don't be embarrassed.  It's embarrassing that

I guess some internet beast swallowed the rest of your letter, but
I second the message that OP should /not/ be embarrassed.  Silly jokes
aside, the question is a valid one.  In fact, there is one area I am
a bit afraid of wrt Emacs & security, and if I may hijack the thread (a
bit), let me ask this: if I edit remote files via TRAMP, can I be sure
not even partial copy of data from the server ends up on my local drive,
e.g. in /tmp?

Also, one area one should be probably /very/ careful are packages which
save "Emacs session" to disk.  If the "session" includes the kill ring,
it may happen (/especially/ if one uses TRAMP to edit remote .env files
and similar stuff) that some password ends up there, which could be
a /very/ serious leakage.

Also, this is obvious, but no guarantees can be made about /any/ package
on MELPA, EmacsWiki or elsewhere.  (Still I think Emacs -- and Vim, for
that matter -- are "safer", at least for some sane values of "safer",
than VSCode etc.)

Best,

-- 
Marcin Borkowski
http://mbork.pl