Request: Update inox to 57

[nyancat18]

57.0.2987.98
source
https://chromereleases.googleblog.com/2017/03/stable-channel-update-for-desktop.html

[hasufell]

Also looking forward to this. 56.0.2924.87 has been very buggy for me. Tabs crashing on various websites, reproducibly.

[gcarq]

I will adapt the patches to 57.0.2987.98 ASAP, but don't expect much work during this week, because unfortunately I'm quite busy right now. Earliest release is this weekend (20.03.2017). As always: every help is welcome :-)

[nyancat18]

@gcarq @hasufell
we dont need the glib patch anymore

https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/chromium&id=ad3f3c9386680b50a17d43649b5eb493b06264c2

[nyancat18]

issue #2
fix without safe browsing

FAILS
reason: chrome/browser/browsing_data/browsing_data_remover.cc has disappeared
https://gist.github.com/triceratops1/94d9f530bcdee7dc7c835949b695c096

[Eloston]

@gcarq I've finished updating ungoogled-chromium's subset of Inox patches to version 57: https://github.com/Eloston/ungoogled-chromium/tree/develop/resources/patches/inox-patchset (I'm running on them right now)

The WebRTC patch was removed since it's applied upstream.

[nyancat18]

@thanks

i gonna test it now :)

[gcarq]

Thanks a lot, I'm back-merging them. Does the upstream WebRTC patch fix the stability issues?, I can't find many infos on that right now.

[Eloston]

@gcarq I'm not aware of any stability issues, so I don't know. What kinds of stability issues are you referring to?

[nyancat18]

@Eloston i've used your patches (your remix of inox)

and i get
[0319/215817.532349:ERROR:icu_util.cc(173)] Invalid file descriptor to ICU data received.
[0319/215817.532516:FATAL:content_main_runner.cc(696)] Check failed: base::i18n::InitializeICU().
#0 0x5558224fdcfe
#1 0x5558225164ce
#2 0x5558221b45ae
#3 0x5558221b35dd
#4 0x555820c56074 ChromeMain
#5 0x7f0d759eb511 __libc_start_main
#6 0x555820c55f0a _start

[Eloston]

@triceratops1 Check your build script. The subset of patches I use don't touch ICU at all.

EDIT: I'm getting the same thing on a Ubuntu Xenial build that doesn't statically link the ICU data in. For some reason, I'm not getting this error when I run from the build output directory...

It seems that there is some change in 57 that we're not accounting for.

EDIT2: Disregard everything I just said. I forgot to include icudtl.dat in the package.

[gcarq]

@Eloston Ok nice. Someone reported a bug for version 56.X where Inox would crash if flash media is accessed (reproducable with enable_webrtc=false). According to a chromium developer code in respect to enable_webrtc=false doesn't get much love:

"I feel like it's highly more likely that things are just broken in general with enable_webrtc=false since it seems to not get tested much (if at all)" [issue #667527].

Lets see if I can reproduce it with 57.0.2987.98.
BTW I'm compiling the new version right know, if anyone is interested: develop branch
I will test it today and if it's stable and nothing pops up it should be releasable by tomorrow.

[gcarq]

@triceratops1 looks like a language translation file is absent or messed up.

[Eloston]

@triceratops1 Check to see if icudtl.dat is next to where the chromium binary is.

[hasufell]

@gcarq how do you verify that data transmission to google is consistently turned off after a new release? Just fixing the patches is probably not enough, unless you code-review the whole version diff of chromium.

[gcarq]

@hasufell I'm tinkering with it in a VirtualBox session with mitmproxy, which can intercept HTTPS traffic if you install the generated CA certificates [link]. I also use a shim to trace connections: netshim

[Eloston]

@gcarq Weird. I don't have Flash with my build of Chromium, so I couldn't run into that issue.

In the long run, I think it's possible that more and more code will depend on WebRTC being enabled, just like it is for Safe Browsing. And unlike Safe Browsing, WebRTC is useful to have, as shown by those who have adopted it already. Perhaps it is worth the time to add a configuration option or command-line flag to toggle WebRTC features (at least stubbing the JavaScript API and other APIs dynamically) in the browser?

[gcarq]

@Eloston Yes you're right, I think this is the only viable way in the long run to not introduce more bugs.

[Eloston]

@gcarq

I'm tinkering with it in a VirtualBox session with mitmproxy, which can intercept HTTPS traffic if you install the generated CA certificates [link]. I also use a shim to trace connections: netshim

Interesting setup, but how do you sift through the large quantities of data from that? Also, how would you be able to distinguish between traffic caused by a webpage and traffic from the browser internals (assuming you visit pages that use Google resources)? Do you leave the monitoring programs running all the time (since some connections are triggered only under very specific conditions, e.g. ungoogled-software/ungoogled-chromium#104 ?)

Yes you're right, I think this is the only viable way in the long run to not introduce more bugs.

Sounds good. There's an issue report on ungoogled-chromium if you want to discuss it more there: ungoogled-software/ungoogled-chromium#179

[gcarq]

@Eloston @hasufell
In the VirtualBox I've mapped some random domain names in /etc/hosts i.e.:

a.com 127.0.0.1
b.com 127.0.0.2
c.com 127.0.1.3
...

On these addresses I serve some static content via a minimal nginx docker container. Then I have a small python selenium script which fetches these sites at random intervals, from there on its easy to filter the traffic in wireshark. Usually I let the vbox running for some days after a new release. The next steps would be to serve some javascript code on those sites and simulate user behaviour with selenium (i.e.: try out each toggle in settings, etc ...).

However I don't think it would catch such connection you mentioned. I usually don't test as a logged in user, because I'm not using Google services except their public API. I don't think you're be able to distinguish between a browser internal and a webpage request on the connection level. Maybe chrome://net-internals/ offers some way to generate a list of visited sites which could be used to diff against the actually visited sites.

Thanks for the link

[hasufell]

Patches apply, inox builds and the overly frequent tab crashes seem to be gone after quick testing. WebRTC still disabled.

[Eloston]

@gcarq Wow, that's quite a setup. Do you manually determine what static content to cache in your nginx docker container?

However I don't think it would catch such connection you mentioned. I usually don't test as a logged in user, because I'm not using Google services except their public API.

You don't need to be logged into Google to trigger it. See ungoogled-software/ungoogled-chromium#111. I'm not exactly sure what triggered that request to happen.

[gcarq]

@Eloston No I use the official nginx image without modifications, all I do is mounting a directory to serve the index.html. Oh ok, very strange. Maybe it is triggered through an extension.

[Eloston]

No I use the official nginx image without modifications, all I do is mounting a directory to serve the index.html.

Oh, I must have misunderstood what you were doing. I thought you were using the docker container to achieve a similar effect to Decentraleyes.

[gcarq]

@Eloston It's just something like this:

docker run --name bdotcom -v /some/content:/usr/share/nginx/html:ro -p 127.0.0.2:8080:80 -d nginx

[gcarq]

@hasufell Nice to hear, thanks for testing.

[nyancat18]

@hasufell
did you touch the icu ??

i'm making it with it (copying the google's icu)

because my "meme" versions (that fail because of icu lacking)

works with the chrome icu

[gcarq]

@triceratops1 How does your PKGBUILD look like? do you have harfbuzz and harfbuzz-icu installed?

[nyancat18]

yes

[nyancat18]

https://build.opensuse.org/package/show/home:meh924f:archlinux/inox

[gcarq]

Took a little bit longer than expected, but version 57.0.2987.98 is now ready. I've modified 0005-disable-default-extensions.patch to remove some predefined extensions from the whitelist:

--- a/chrome/browser/extensions/component_extensions_whitelist/whitelist.cc
+++ b/chrome/browser/extensions/component_extensions_whitelist/whitelist.cc
@@ -30,8 +30,6 @@
 
 bool IsComponentExtensionWhitelisted(const std::string& extension_id) {
   const char* const kAllowed[] = {
-    extension_misc::kHotwordSharedModuleId,
-    extension_misc::kInAppPaymentsSupportAppId,
 #if defined(ENABLE_MEDIA_ROUTER)
     extension_misc::kMediaRouterStableExtensionId,
 #endif  // defined(ENABLE_MEDIA_ROUTER)

This is a defensive mechanism to block potential extension downloads during runtime.

[nyancat18]

THANKS

[hasufell]

Hm, I still have stability issues. Tabs are still crashing on some sites.

[gcarq]

@hasufell Yes me too. I'm planning to enable webrtc with the next release.

[hasufell]

I have it enabled, it didn't change anything.

[gcarq]

Dang

[Eloston]

@hasufell Are you getting crashes on regular Chromium, Chrome, or other Chromium-based browsers? Do you have a stack trace (with the symbol names) of the browser when the crashes happened? This should give us an idea if the problem you're facing is with Chromium or with the changes made in Inox.

[hasufell]

@Eloston no crash in vanilla Chromium, tried both with a clean profile directory

e.g. this site reliably crashes with inox https://i.imgur.com/FGy1ZKq.gifv
(sometimes I need to reload 1-2 times before it crashes)

[Eloston]

@gcarq Will WebRTC be permanently on in all future releases, or are you planning to add an option to switch it off?

[gcarq]

@Eloston I'm planning to add an option to switch it on/off

@hasufell Can you try with the latest version, it seems to be fixed (cannot reproduce).

[nyancat18]

settings list (clearnet) :
name: CryptoCartel searx

url: cryptocartel.com

search url: https://cryptocartel.com/search?q=%s

settings list (tor) :
name: CryptoCartel searx

url: wscvq7ru5saua556.onion

search url: http://wscvq7ru5saua556.onion/search?q=%s

[hasufell]

Not fixed for me, I still have those tab crashes. The only difference between my chromium build and the inox build are

a) the inox patches
b) the following chromium settings (similar to the PKGBUILD)

    myconf_gn+=" enable_hangout_services_extension=false"
    myconf_gn+=" enable_rlz=false"
    myconf_gn+=" enable_rlz_support=false"
    myconf_gn+=" enable_remoting=false"
    myconf_gn+=" enable_google_now=false"
    myconf_gn+=" safe_browsing_mode=0"
    myconf_gn+=" enable_webrtc=true"
    myconf_gn+=" enable_hotwording=false"
    myconf_gn+=" enable_print_preview=false"

So this looks like it's caused by the inox patches imo.

[gcarq]

Yes I think so too, I will look into it.

[perfect7gentleman]

@hasufell, do you use inox-patchset or ungoogled-chromium patches ?

[Eloston]

To add onto what @perfect7gentleman asked, I'm not experiencing any crashes on the link above on ungoogled-chromium 57.0.2987.133. However, I am running uBlock Origin with uBO-Extra, so I'm not sure if that makes a difference.

The only website that has crashed my browser process so far is the Epic Zen Garden demo from Mozilla: http://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html. I'm not sure if this works properly on regular Chrome or Chromium, though.

[perfect7gentleman]

@Eloston, the same. I got *.146 with ungoogled patches, so far no problems, except Epic Zen Garden demo from Mozilla

[hasufell]

@perfect7gentleman Inox patchset only of course. This is the inox issue tracker ;)

I have to add, that I compile chromium and inox myself of course. So stability issues might also depend on the toolchain. However... for just chromium compiled with the same toolchain, I get no crashes whatsoever.

[gothmog123]

@gcarq
You're planning to add an option to switch webrtc on/off - does that mean it will be enabled at compile time for binary packages and there will be a runtime option? Thanks and sorry to bother you with this.

[Eloston]

@gothmog123 From what I know, probably yes. The enable_webrtc GN flag will be enabled and there will be a runtime option in either chrome://settings or chrome://flags to switch it on and off.

[gothmog123]

Awesome, thanks.

[gcarq]

@gothmog123 Sorry for the long delay. Yes it is planned to implement a runtime option to enable/disable webrtc as described by @Eloston. For now webrtc is enabled by default to mitigate some crashes.

@hasufell Yes seems like an issue with some inox patch, please create a new issue to track this bug.

I'm closing this issue because Chromium 58 is out, please switch to this issue for update discussions: #74