On Sat, Aug 29, 2015 at 1:07 AM, Michael Catanzaro <mcatanzaro@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.