Of customisability, overridability and FLOSS/LibreOffice's mission

[Lionel Elie Mamane]

On Fri, Jun 13, 2014 at 09:44:42AM +0100, Noel Power wrote:
> On 12/06/14 16:16, Lionel Elie Mamane wrote:
>> On Fri, Jun 06, 2014 at 09:55:05AM +0100, Noel Power wrote:
>>> On 28/05/14 12:11, Lionel Elie Mamane wrote:

> >> Security, I mentioned it in a previous mail, what you are suggesting is
> >> basically allowing the user to rootkit the libreoffice api.

>> I'm surprised you consider LibreOffice a security barrier /
>> enforcer. I don't. As I see it, factually, it is an application that
>> runs with the user's identity and privileges, that is under the
>> control of the user and of anybody that subverts the user's
>> environment. (...)

> (...) It's clear you are comfortable with the idea that a user
> extension can override the core, a hypothetical example being say of
> a user installing a user extension that overrides the allows a user
> XProtectable so they can easily unlock any spreadsheet to unhide
> their bosses salary.

(This is an interesting point, but is besides the access2base
 discussion. I'm forking it into a separate subthread.)

That's actually a good example, and similar to what I do with my PDF
readers to allow me to copy (for paste for quotation) / print /
... (that is, ignore the permissions bits).

In your example, the boss's salary is available with the combination
of "unzip / xmlindent / less" anyway, so I don't see it as being
secret; if one does not want the employees to know that piece of
information, then *don't* *send* *a* *file* *that* *contains* *the*
*information* *to* *them*. Not even wrapped in a "please don't read
that" (which is what this "please program under control of the user,
don't show this to the user" amounts to). Enticing "boss" users to do
that is just a rotten ecosystem, although I do recognise that for
compatibility reasons, we may have to "support" the features that make
the ecosystem rotten. However, (were I benevolent dictator,) I would
make it a point of differentiation that, while our software has "the
feature" to live up to behaving bug-to-bug compatible with "the other
office suite", we *do* *not*, contrary to "the other office suite",
make *false* *promises* of security to our users (nor lure them into a
false sense of security).

Now that I think of it, LibreOffice has an indirection level that
"service names" are mapped to "implementation names" by way of
*configuration* files, the ".component" files. So I wouldn't be too
surprised that by mapping a service name that is usually provided by
core to an implementation in an extension, the kind of things you
describe is *already* *possible*. Any LibreOffice code (even from
core) instantiating the service would get the implementation from the
extension (independent on the particular example, whether XProtectable
is implemented in a service or not...). Never tested it, though.

> But... the issue here isn't the silly example it's the fact that
> libreoffice itself uses the api, it expects the code it calls via
> the api to be the code it shipped with and to behave exactly how it
> expects, this is one of the boundaries (or at least how I read it)
> that Michael mentioned previously and one of the invariants the core
> expects.

Taking the role of the user, *this* *is* *my* *computer* and my
installation of LibreOffice. Let me screw it up if I want. I see us
(LibreOffice project, Free Software movement in general) as being
about empowering the *user*.

You want to throw away my bug reports because I have an extension that
overrides the core? Fair enough (that's similar to Linux (the kernel)
throwing away bug reports from tainted kernels, for example).

You want to make me pay more for paid support because I have an
extension that overrides the core? Fair enough.

-- 
Lionel