Let's reconsider some more applications installed by default

[Elad Alfassa]

On Sat, Aug 29, 2015 at 1:07 AM, Michael Catanzaro <mcatanzaro at gnome.org>
wrote:

>
>
> > You are biased, as you said before. Epiphany still has rendering
> > problems in many websites,
>
> The rendering code is actually almost all cross-platform, so such
> issues usually affect Safari as well. But in practice, issues are quite
> rare nowadays. I've been using Epiphany for three years now and the
> progress is apparent.
>

Well, some of the issues are webkitgtk specific, such as the ones where it
pretends to be other browsers and break the entire world while doing so.


>
> >  it doesn't support privacy-enhancing extensions such as privacy
> > badger and HTTPS Everywhere
>
> I am in favor of built-in support for HTTPS Everywhere, enabled by
> default, using [1]. This should be fairly easy to implement, since most
> of the work is already done in [1].
>
> I don't want to support Privacy Badger: I tried it last week and I
> noticed a broken site almost immediately. The EasyPrivacy list seems to
> not break things at least, so we could use that. And Firefox has a new
> list (off by default and hidden) that we could use. We should look at
> EasyPrivacy as the quickest step forward, since it's just a matter of
> hooking it up to the existing adblock filters. This is probably just a
> weekend hack; I just haven't found time recently. :(
>
> [1] https://github.com/grindhold/libhttpseverywhere/


Privacy Badger does more than just blocking well known trackers: it detects
some fingerprinting techniques such as canvas fingerprinting and blocks
them.


>
>
> > , it doens't support custom adblocking lists (the default adblocking
> > list only works for global websites and not for local ad networks in
> > my country, for example!)
>
> I agree, we need to add UI for this. In the meantime, you can create
> ~/.config/epiphany/filters.list containing a semicolon-separated list
> of URIs (e.g. https://easylist-downloads.adblockplus.org/easylist.txt).
> But that's of course not an acceptable solution we can give to users.
> And it should be smart enough to pick a locale-specific blocklist
> automatically.
>

You can't pick a locale specific blocklist automatically. I live in Israel
and use an English locale, and I use many Israeli websites and many global
websites. In reality, I need (at least) two lists, and you have no
automatic way to detect which ones I'm going to require.


>
> >  it doesn't support many newer web platform APIs,
>
> Again, we support a comparable set of features to Safari; I don't think
> this is really a problem.
>

Do you know any web developer that actively uses Safari as their default?
Web developers are part of our target audience.
I should also point out that Epiphany's developer tools are almost
unusable, compared to Firefox which has something that already works well
out of the box and extensions you can install if you need something extra.


>
> >  doesn't have a sync solution... the list goes on and on.
>
> I agree this would be great to have.
>

Do you think that in 2015, where most people have at least two devices
(phone + laptop, for example), we can have a default browser without a sync
solution?


>
> > SELinux policy bugs are less common nowdays, indeed. This still
> > doesn't mean we don't need the notifications to exist.
> > (also it would be nice if SELinux could actually do more useful stuff
> > such as blocking random apps like Steam or Firefox from stealing your
> > SSH private key... that PDF-based attack that stole Firefox users'
> > private keys could easily be mitigated by SELinux if we had a policy
> > for that in place)
>
> It would be nice to keep the notifications, but I think it's less
> important than ensuring the default set of applications is reasonably
> user-friendly.
>

It's hidden in Sundry for a reason. FWIW apple also has bullshit hidden
away in folders in their app menu by default and it doesn't "hurt their
default offering" too much/


> > This is a severe problem that shouldn't be ignored.
>
> But upstream is dead, so it will be ignored. :(
>
> I also filed: https://bugzilla.gnome.org/show_bug.cgi?id=747030
>
> In general, any application that uses libsoup directly, or uses
> obsolete versions of WebKit, likely does certificate verification wrong
> and should be audited to find out. Nobody is going to do that, of
> course.
>

Well, we should not ship a default app with a dead upstream. It's better to
ship something which is not yet fully mature than something that is
outright insecure.


>
> >  At the very least, we need to disable all social functionality in
> > Shotwell until this is solved. This has serious implications on user
> > safety.
>
> +1 from me, though it might be easier to fix... anyway, note that I
> haven't confirmed this to be an issue: I merely noted the quite high
> probability that it is an issue.
>

Can you please check if what you're saying is correct, so we can patch it
out of shotwell if it is?


>
> > Also, please make sure you make it more well known next time you know
> > about a (publicly known) severe security issue in one of our default
> > (or commonly used) apps.
>
> Probably should have, but I guess I am just depressingly used to such
> things at this point... anyway, the certificate verification issue is
> not more serious than Shotwell's use of WebKit1, which should be well
> -known.
>

Not everyone are familiar with the gory details of webkit. It's not obvious
to most people.


>
> > If this was not publicly known before you mentioned this on your
> > mailing list (I mean, I guess everybody knew it uses an old webkit,
> > but it's possible that not everybody knew old webkit doesn't verify
> > certificates), this is even worse... please make sure to responsibly
> > disclose security bugs privately if this is the case.
>
> GNOME doesn't have any policy for security bugs, nor does it have priva
> te bug reports. I don't really think private reports are a good idea,
> either, unless they are timed and become public automatically after a
> few weeks.
>

Fedora has an option to mark a bug as a security sensitive one, which hides
it from the public. This is the correct way to report a security bug. This
is called "responsible disclosure" and is a very important practice in the
infosec industry. If you disclose a security issue publicly, people who
didn't know about it before might start exploiting it before you can ship a
fix to your users.


-- 
-Elad.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/desktop/attachments/20150829/f024124b/attachment.html>