Re: sane chromium default flags - include --enable-remote-extensions

2017-02-28 Thread Andrey Rahmatullin 
On Wed, Mar 01, 2017 at 01:17:24AM +, Reinhard Tartler wrote:
> > > I can see that the behaviour you describe would be very annoying.
> > When updating extensions is disabled, it is a "good" thing that you cannot
> > install them and use installed ones.
> It's certainly *not* good. It may be "safe", but is also dissatisfying to
> many users because it disables functionality, which causes a lot of
> immediate frustration.
That's why the quotes.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: sane chromium default flags - include --enable-remote-extensions

2017-02-28 Thread Reinhard Tartler 
On Mon, Feb 27, 2017 at 10:40 AM Andrey Rahmatullin  wrote:

>
> >
> > I can see that the behaviour you describe would be very annoying.
> When updating extensions is disabled, it is a "good" thing that you cannot
> install them and use installed ones.
>

It's certainly *not* good. It may be "safe", but is also dissatisfying to
many users because it disables functionality, which causes a lot of
immediate frustration.

The previous behavior of allowing users to download, but not update
extensions, is putting users at risk if the extension needs updating for
security reasons, or at best causes frustration for not getting
functionality updates.

In an enterprise setup, where the system administrator chooses to limit his
users ability to what extensions can be installed, disabling external
extension might make a lot of sense. Arguably, the majority of our users do
not fall in this category.

Is it really worth the trouble of trying to "protect" users from privacy
issues?

Maybe the Debian chromium package can be enhanced to target the typical
(i.e., the majority of our) users first, and offer configuration settings
in /etc that allow non-typical users to adjust to their specific
requirements?

Best,
Reinhard

Re: sane chromium default flags - include --enable-remote-extensions

2017-02-27 Thread Ian Jackson 
Andrey Rahmatullin writes ("Re: sane chromium default flags - include 
--enable-remote-extensions"):
> [Ian Jackson:]
> > Can we not make the updates work for non-Debian-packaged extensions,
> > while disabling them for Debian-packaged ones ?
> > 
> > If we did that then there would no need to disable people's
> > extensions.
> 
> I guess the real question is "why updating extensions was disabled
> in the first place". If chromium phones home only when non-packaged
> extensions are actually installed then it doesn't happen until the
> user installs them.

But is that actually true ?

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841401#89

I don't know what `background networking' is, precisely, in this
context, but it doesn't sound like something nice.

It still seems likely to me that the problem here is a code problem,
and that people who find the current behaviour unpleasant should try
to figure out how to make the code DTRT, rather than fighting over a
bad choice between different bad default configurations.

> I'm sure there are people who would forbid the
> users from doing that but...

This is a separate question.  Ideally, as I say, Chromium would not
access external repositori(es) for extensions unless they either
contain only Free Softare, or the user has enabled Debian control
(and, presumably, installed some chromium-nonfreeapp-store package, or
something).

But certainly it should not phone home for extensions unless the user
explicitly asks to review or search for available extensions, or has
non-Debian-packages extensions installed.

Ian.

Re: sane chromium default flags - include --enable-remote-extensions

2017-02-27 Thread Andrey Rahmatullin 
On Mon, Feb 27, 2017 at 04:43:29PM +, Ian Jackson wrote:
> > > Do we know why this is ?  Is this an unintended side effect of some
> > > other change ?  Has someone done this deliberately and if so have they
> > > explained what they were trying to achieve ?
> > > 
> > > I can see that the behaviour you describe would be very annoying.
> >
> > When updating extensions is disabled, it is a "good" thing that you cannot
> > install them and use installed ones.
> > That's what the original bug was about.
> 
> I'm not sure I have parsed your reply correctly, so let me repeat back
> what I think you are saying:
> 
>   Since online updates to non-Debian-packaged extensions are disabled,
>   it is necessary to prevent installation or use of
>   non-Debian-packaged extensions at all: otherwise, users would be
>   running extensions without security updates.
Indeed.
#841401 is more or less this:
- my extensions cannot be updated
- that's to address some of the concern about unrequested network
  connections
- if you disable updating extensions then you should disable installing
  them too as the current situation is stupid
- done

> Well, the reasoning is sound, but this does not seem like a desirable
> situation.
That's true. That's why the usual reaction to #841401 outcome is "huh?".

> Can we not make the updates work for non-Debian-packaged extensions,
> while disabling them for Debian-packaged ones ?
> 
> If we did that then there would no need to disable people's
> extensions.
I guess the real question is "why updating extensions was disabled in the
first place". If chromium phones home only when non-packaged extensions
are actually installed then it doesn't happen until the user installs
them. I'm sure there are people who would forbid the users from doing that
but...


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: sane chromium default flags - include --enable-remote-extensions

2017-02-27 Thread Ian Jackson 
Andrey Rahmatullin writes ("Re: sane chromium default flags - include 
--enable-remote-extensions"):
> On Mon, Feb 27, 2017 at 03:14:08PM +, Ian Jackson wrote:
> > Do we know why this is ?  Is this an unintended side effect of some
> > other change ?  Has someone done this deliberately and if so have they
> > explained what they were trying to achieve ?
> > 
> > I can see that the behaviour you describe would be very annoying.
>
> When updating extensions is disabled, it is a "good" thing that you cannot
> install them and use installed ones.
> That's what the original bug was about.

I'm not sure I have parsed your reply correctly, so let me repeat back
what I think you are saying:

  Since online updates to non-Debian-packaged extensions are disabled,
  it is necessary to prevent installation or use of
  non-Debian-packaged extensions at all: otherwise, users would be
  running extensions without security updates.

Well, the reasoning is sound, but this does not seem like a desirable
situation.

Can we not make the updates work for non-Debian-packaged extensions,
while disabling them for Debian-packaged ones ?

If we did that then there would no need to disable people's
extensions.

(Of course a user should not be invited to install extensions from an
upstream or third-party extension repository, unless that repository
contains only free software, or the user has enabled Debian contrib -
but I think that's a separate question.)

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: sane chromium default flags - include --enable-remote-extensions

2017-02-27 Thread Andrey Rahmatullin 
On Mon, Feb 27, 2017 at 03:14:08PM +, Ian Jackson wrote:
> > It's not even about updating: the first version of chromium with this
> > build-time tweak simply disabled all already installed extensions for me
> > so they were not activated when I restarted chromium after that upgrade
> > session -- and hence were not shown in UI etc.
> > What's worse, it's futile to attemt to reinstall them: the settings tab
> > for the extensions works OK, the chromiums "extensions store" (whatever
> > its real name is, I dunno) works OK, just when you try to install an
> > extension, you get some mystical error message having nothing to do
> > with what Debian's build did, and with no hint at what to do next.
> 
> Do we know why this is ?  Is this an unintended side effect of some
> other change ?  Has someone done this deliberately and if so have they
> explained what they were trying to achieve ?
> 
> I can see that the behaviour you describe would be very annoying.
When updating extensions is disabled, it is a "good" thing that you cannot
install them and use installed ones.
That's what the original bug was about.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: sane chromium default flags - include --enable-remote-extensions

2017-02-27 Thread Ian Jackson 
Konstantin Khomoutov writes ("Re: sane chromium default flags - include 
--enable-remote-extensions"):
> It's not even about updating: the first version of chromium with this
> build-time tweak simply disabled all already installed extensions for me
> so they were not activated when I restarted chromium after that upgrade
> session -- and hence were not shown in UI etc.
> What's worse, it's futile to attemt to reinstall them: the settings tab
> for the extensions works OK, the chromiums "extensions store" (whatever
> its real name is, I dunno) works OK, just when you try to install an
> extension, you get some mystical error message having nothing to do
> with what Debian's build did, and with no hint at what to do next.

Do we know why this is ?  Is this an unintended side effect of some
other change ?  Has someone done this deliberately and if so have they
explained what they were trying to achieve ?

I can see that the behaviour you describe would be very annoying.

Ian.

Re: sane chromium default flags - include --enable-remote-extensions [and 1 more messages]

2017-02-27 Thread Ian Jackson 
Michael Gilbert writes ("Re: sane chromium default flags - include 
--enable-remote-extensions [and 1 more messages]"):
> On Fri, Feb 24, 2017 at 10:05 AM, Ian Jackson wrote:
> > It seems likely to me that this is a bug, not some kind of
> > "ideological mistake".
> 
> You basically nailed it, especially since I don't care either way [0].
> 
> People are yelling must have safe defaults on one side.
> And people are yelling must have unsafe defaults on the other.

I looked at #856183 but I don't understand it.  What does `safe' or
`unsafe' mean ?  Are we still talking about whether to phone home for
extension updates ?

Ian.

Re: sane chromium default flags - include --enable-remote-extensions [and 1 more messages]

2017-02-25 Thread Michael Gilbert 
On Fri, Feb 24, 2017 at 10:05 AM, Ian Jackson wrote:
> It seems likely to me that this is a bug, not some kind of
> "ideological mistake".

You basically nailed it, especially since I don't care either way [0].

People are yelling must have safe defaults on one side.
And people are yelling must have unsafe defaults on the other.

The negativity from both sides is disheartening.  Can't we all just
get along [1]?

Best wishes,
Mike

[0]http://bugs.debian.org/856183
[1]http://www.huffingtonpost.com/jenna-brownson/cant-we-all-just-get-alon_3_b_10150704.html

Re: sane chromium default flags - include --enable-remote-extensions

2017-02-25 Thread Konstantin Khomoutov 
On Fri, 24 Feb 2017 15:14:18 +0100
m...@linux.it (Marco d'Itri) wrote:

> > To be honest I've the feeling that we're doing a disservice to our
> > users when we release stretch with the current defaults. Putting
> I amazed by this decision: this is the kind of thing that makes
> people not take Debian seriously.
> This behaviour should either be implemented consistently by all
> browsers or the default reverted.
> Users expect their browser to update the extensions that they have 
> installed themselves, so the excuse about "unrequested network 
> connections" looks like just an ideological decision.

It's not even about updating: the first version of chromium with this
build-time tweak simply disabled all already installed extensions for me
so they were not activated when I restarted chromium after that upgrade
session -- and hence were not shown in UI etc.
What's worse, it's futile to attemt to reinstall them: the settings tab
for the extensions works OK, the chromiums "extensions store" (whatever
its real name is, I dunno) works OK, just when you try to install an
extension, you get some mystical error message having nothing to do
with what Debian's build did, and with no hint at what to do next.

I possess the necessary google-fu and I'm a programmer after all, so
that wasn't too hard for me to find the cause and implement the
solution, but for a plain computer user that would be a complete
dead-end.

Re: sane chromium default flags - include --enable-remote-extensions [and 1 more messages]

2017-02-24 Thread Ian Jackson 
Sven Hoexter writes ("sane chromium default flags - include 
--enable-remote-extensions"):
> I've found the issue to be tracked in https://bugs.debian.org/851927

I found that bug rather unenlightening TBH.

Marco d'Itri writes ("Re: sane chromium default flags - include 
--enable-remote-extensions"):
> Users expect their browser to update the extensions that they have 
> installed themselves, so the excuse about "unrequested network 
> connections" looks like just an ideological decision.

I think if the user does not install extensions[1], Chromium should
not phone home.  Do you agree ?

If the user does install extensions from the upstream extension
repositories, then Chromium must phone home to check for updates to
those extensions.  (This is surely necessary to get security updates
to the extensions.)

[1] Extensions provided as Debian packages do not count, as they
should be updated via apt.  So whatever mechanism can't simply ask
"are there any extensions?"; it has to somehow ask "are there any
extensions we need to phone home about?"

It seems likely to me that this is a bug, not some kind of
"ideological mistake".  Chromium is a complicated program and it's
full of spying stuff.  Probably someone completely disabled this
particular phone-home without thinking through all the implications.
Or perhaps making the extensions phone-home conditional is hard.

Does that make sense ?

Ian.

Re: sane chromium default flags - include --enable-remote-extensions

2017-02-24 Thread Marco d'Itri 
On Feb 24, Sven Hoexter  wrote:

> To be honest I've the feeling that we're doing a disservice to our
> users when we release stretch with the current defaults. Putting
I amazed by this decision: this is the kind of thing that makes people 
not take Debian seriously.
This behaviour should either be implemented consistently by all browsers 
or the default reverted.
Users expect their browser to update the extensions that they have 
installed themselves, so the excuse about "unrequested network 
connections" looks like just an ideological decision.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

sane chromium default flags - include --enable-remote-extensions

2017-02-24 Thread Sven Hoexter 
Hi,
based on some random chatter on IRC I noticed that many people now
have their own way of passing --enable-remote-extensions to chromium.
The workarounds range from system wide stuff in /etc/chromium.d/ to
local aliases or script wrapper in a ~/bin/chromium script.

To be honest I've the feeling that we're doing a disservice to our
users when we release stretch with the current defaults. Putting
reasonable security considerations aside I think we should cater our
users and ship a chromium release with reasonsable defaults, so we
do not have to invent our own workarounds to pass just the same flag
in different ways to have a usable chromium.

Michael, Riku what's your take on this issue?
I've found the issue to be tracked in https://bugs.debian.org/851927
but that did not offer any rational about why it's not a default setting
so chromium works like it did in the past.

Maybe my viewpoint is a bit limited because I only use chromium when I've
to rely on some Chrome extensions and otherwise use Firefox. So I was
confused when I noticed this behaviour change and it took a a few minutes
and some grief to figure what had changed

Sven