So... It's still probably safer with the free grsec kernel (dappersec)... Sorely missing the protections from Meltdown and Spectre, but most other protectiions are in place. And pls. note that it's a dev from the KSPP team. Hardly biased towards grsec.

No, it's probably not... While I haven't sudied those in depth, it's probably the Meltdown and Spectre that are the most important to have countermeasures in your kernel against, and grsec/dappersec can't at this time, and there seem no interest from spender and PaX Team, the authors... and grsec/dappersec can't protect you from those...I think I'm closing my engagement with what is left in the open FOSS world of grsecurity.

...Reading this and the other comments makes clear that we need to improve documentation what and why we changed things. All the trk-xxx.iridiumbrowser.de hosts are there to find connections which we were not able to disable yet. All these end up at nothing (404 not found) and are not proxied in any way. Essentially Iridium browser should never contact them - if it does then it is a code path we have missed and a bug.

It is perfectly possible that they needed something like just a ping to figure out where else original Chromium leaks user data. That's why it was sufficient to them to just have that part of the info, and it is possible that they were not collecting user data.

The ip address 88.198.85.193 will take you to the Iridium page page, so I'm not sure what the dev is trying to convey there. I'm willing to believe that they aren't collecting data, but it is strange that it is clearly going to their page. I'm also not really interested in skimming any tcpdump packets, because, as you said earlier, the stream is encrypted (port 443), so I doubt there's anything substantial in the network stream.

Oh no, it's under encryption where most all is really happening!

I just wanted to confirm if it was reaching out at all. As I mentioned, whatever part of the code that's reaching out to 88.198.85.193 is not in the same place as it was when the ycombinator article was written, so I'm interested to find out where it is now, and what else it might be doing, based on the source code, not the tcp stream.

It's an interesting subtopic. But time in too short supply here...They likely needed to find where their not completely spyware-purged Iririum still leaked user data...I searched the other day, after learning about that ycombinator page on Iririum, but could not find the page somewhere under the https://torproject.org with the article by Mike Perry, the lead Tor developer... In which he explains how Chrome leaked user IP...That was in the time when Chrome was considered for Tor instead of Firefox. Not afterwards...Just telling this example for comparison to this Iridium episode...It's the lead developer. The author of vanguards, if you're following Tor development...It took a lot of brains to figure that leak, you know... That's programming... Wizards can hide lots of things in the code, and hide it well...Regards!

tcptrackSoftwareTcptrack is a packet sniffer, which passively watches for connections on a specified network interface, tracks their states, and lists them in a manner similar to the Unix 'top' command (GPL, Internet, Utilities, Networking, Monitoring).More at Freshmeat

...Reading this and the other comments makes clear that we need to improve documentation what and why we changed things. All the trk-xxx.iridiumbrowser.de hosts are there to find connections which we were not able to disable yet. All these end up at nothing (404 not found) and are not proxied in any way. Essentially Iridium browser should never contact them - if it does then it is a code path we have missed and a bug.

It is perfectly possible that they needed something like just a ping to figure out where else original Chromium leaks user data. That's why it was sufficient to them to just have that part of the info, and it is possible that they were not collecting user data.

Humble Bundle sells groups of e-books at ridiculously low prices, DRM free. This month, the bundles are all Wiley titles, including three of my books: Applied Cryptography, Secrets and Lies, and Cryptography Engineering. $15 gets you everything, and they're all DRM-free.

I would have been willing to pay, but it vanished within not much longer than a week... Anybody got those?

NOTE: that's a digression, and while I thought hard if it is appropriate to ask about it here, and believe it is within the permissible, I accept whatever the admins/moderators decide, if they decide to the contrary.. Even delete this digression... Or if the option is offered, move it in Off-topic...

Another one would be: I want SSL-logging, as I always want to check what happened online.

Anybody knows that would be workable with Otter?

You should ask Emdek about that on Otter's IRC channel.

I'll remember your advice... If I go that route. (I'm also considering Iridium. Ah, on a longer run. I work pretty slow...)

miroR wrote:

[...]UPDATE: I actually downloaded:1d7058c1972442c72f0904c6b7f3ad9f25dbb11c257d918c857eb74ccb8031fe otter-browser-0.9.99.3-rc12-x86_64.AppImage(the SHA256 is in view of verification; how do AppImage's verify?)and only then took notice my openssl is too new. A no go for me, not messing with such important packages as openssl.

The bigger problem is that Otter Browser requires at least Qt 5.10, which is not in ASCII. But if you had that, it would be possible to built it against openssl 1.1 as well, says the main developer. (I haven't tried that, though.)

It's not clear how bad those "Replace URLs to Google services by URLs to our own server" was...

Not what I expected to read from someone so committed to projects like grsec. Am I in a coma...?

You're fine.Ah, grsec... I'm not an expert. And grsec really may be dying, the FOSS grsec, and Google taking over GNU/Linux security, which is a disaster. But the link in my signature is dead, because my participation in the thread is, for untold reasons, deleted... Where I was telling about it...No geniuses to take up the FOSS grsec, or no way to get spender and pipacs to give us a boost... The meltdown and spectre are deadly flaws, and the FOSS grsec, the dappersec can't protect you from them...

Anyways,

...it's old. And it's unsolved...Anybody knows of a follow-up where that issue was better explained, cleared up?

I wouldn't necessarily say unsolved so much as "probably unexplored." The troublesome code, according to the user "skymt", is located in chrome/browser/history/web_history_service.cc. I don't see that file in the source code anymore. I skimmed through similarly-named files and didn't see any explicit URLs.https://github.com/iridium-browser/irid … er/historyThat's not to say that a similar function isn't embedded elsewhere in the source, though.

One thing I have not yet tried (which I assume someone has, by now) is opening up a tcpdump session with iridium. I do have all telemetry disabled, to the best of my knowledge, so I'll be interested to see what can be found, and what happens when I use a blank config folder.

That was really what was missing in the analysis. I regularly examine tcpdump (actually I run my https://github.com/miroR/uncenz program whenever I'm online) sessions, and for what I understand (I can't tell for all events, such as where Javascript goes really complex), Pale Moon behaves well, of course, thanks to addons NoScript, UBlockO and Decentraleyes at work, as well.

[ I leave the below even though I'm sure you know it, for other readers ]But to do any proper dumpcap or tcpdump sessions analysis, you have to have the SSL-key logging on. Else it's all encrypted, and you see nothing really -- unless you browse in HTTP... But I guess you know it, and you do have it on.Pity I'm out of time, but I think I wish to look much deeper into Iridium, and possibly try to install it and use it.

But that's wrong way to do it... The first line, the "wget -qO ...". It's worth filing an issue on their Github or wherever they have it (writing in a rush, busy)...The right way is...It is how I explained in:A repo serving Pale Moonhttps://dev1galaxy.org/viewtopic.php?id=1972(just: that Pale Moon is now too old, and not to be used that might be gotten from the links to my location there)But I have not time to go and search... I't in the Debian Wiki how it needs to be done, with unofficial repos.

But it's old. And it's unsolved. It's not clear how bad those "Replace URLs to Google services by URLs to our own server" was... Maybe truly for the sake of fixing things...Anybody knows of a follow-up where that issue was better explained, cleared up?Anybody can show us what really happened by posting what s/he sniffed on the network while Iridium was contacting those servers? Did those really come up with 404 Not Found ?

UPDATE:Ah, I see another thing is missing for me with the iridiumbrowser.de repo (*) linked above: can the repo be reached with tor? Anybody? I just can't tell how enjoyable the privacy of Tor is, for installing you packages. Wouldn't want to relinquish that...

(*) BTW the .de is just fine with me, a few important FOSS people have indicated Germany as a possibly leader in privacy

Linux users can use the official AppImage version available on SourceForge. It is a single executable file that doesn’t need any dependencies to be installed. The AppImage version should run under any system installed after 2012 provided it has OpenSSL 1.0.x (not 1.1.x) and GStreamer 1.x (with codecs). The browser is also available in the repositories of a wide range of Linux distributions and *BSD systems. Read more on the dedicated wiki page.

UPDATE: I actually downloaded:1d7058c1972442c72f0904c6b7f3ad9f25dbb11c257d918c857eb74ccb8031fe otter-browser-0.9.99.3-rc12-x86_64.AppImage(the SHA256 is in view of verification; how do AppImage's verify?)and only then took notice my openssl is too new. A no go for me, not messing with such important packages as openssl.

Also why have some distros stopped packaging it? E.g. the last PPA on Launchpad is 3 months ago...UPDATE: no that's not an issue; that's just packagers working ona rare schedule, the thing is: some pages there ( https://launchpad.net/~otter-browser/+a … untu/daily ) are called daily. No worry...But why are there no Debian packages?

Gentoo can be completely no-dbus because you get to compile ALL your packages.

Very true! I know that so well. Years building my Gentoo in different systems.

(Anyone is welcome to recompile all the debian/devuan packages that require libdbus*)

(The stress is again on: ALL [the debian/devuan packages].)We are yet to see if a true non-dbus happens anywhere in the debian world of derivatives, or somewhere else, in such way that not such huge work is needed to accomplish that freedom, or if it does not happen anywhere in the whole GNU/Linuxdom, but only Gentoo.

Refracta-nodbus has libdbus-1-3 and libdbus-glib-1-2. I don't think they do anything except satisfy some package dependencies.

]But that's the core dbus... Something from the heart of Gnome/RedHat... for the world domination that was to be...

A search for 'dbus' in /var/log/* shows some errors in the refractainstaller log and in Xorg.0.log.

Sometimes it downright spams the log in my beowulf Devuan. But I do hope those are innocuous.

refractainstaller_error.log:

D-Bus library appears to be incorrectly set up; failed to read machine uuid: Failed to open "/etc/machine-id": No such file or directory
See the manual page for dbus-uuidgen to correct this issue.

Yeah, I see these all the time, such as when I start Wireshark...

Xorg.0.log:

(EE) dbus-core: error connecting to system bus: org.freedesktop.DBus.Error.FileNotFound (Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory)

I'm not sure what question I'm supposed to answer from stevepusser's post. This? libgtk-3-dev is installable in ascii. I tried to install it, but I already have the latest version.

Looking up more closely, my fault to have wandered there too much... and for not having a clear question about it myself...

I did install successfully libgtk-3-dev, and it did bring in libqt5dbus5 and not much more... (And I did build Pale Moon successfully, after bannishing gconf from build time dependencies...)Ah... I thought we'd be having full sans-dbus in Devuan like Gentoo have (as option)...

@fsmithred, is this no-dbus Refracta also libdbus-free as well?(And also see there, in particular stevepusser was wondering about things that you could possibly known the answer too:[ same topic as the of the already given link ]https://forum.palemoon.org/viewtopic.ph … 94#p147227 )

EDIT: I can't believe I calculated as if the Earth revolved the opposite direction around the Sun than it does... It wasn't night, but it was morning or even early morning in the U.S. when I posted that question about mozconfig... (BTW, I can do complex things, but I sometimes fail on binary stuff, or completely simple stuff, such as I failed my driving exam 42 yrs ago on driving backwards ...Aarrgh!...)

IOW, it's full daytime still in the U.S, while night is drawing over Europe where I live... Just why not answer... How can I compile if I don't know I can at least get some of the options to the liking of a good part (and to no detriment to others) of Devuan users?

I'm not going to be compiling a dbus- nor pulseaudio- Pale Moon... They hopefully will support those options...

Change --enable-official-branding to --disable-official-branding and rename your package in debian/control to whatever name you like. I think so long as you don't use their artwork and don't call it palemoon you should be fine.

lf I remember the browser will call itself "New Moon" by default. That would seem ok in the meantime, but you'd want to rename eventually I think.

Otherwise just use the mozconfig they provide, but it will limit you to the defaults.

I see, but the better way is to try and get Moonchild and his friends confident of my packages and get them to allow the official branding to remain...

In case the few options that I'm pretty unwilling to change, and they're not so many, get a PASS from New Tobin Paradigm, see:

which I hope they will, I am motivated to work more. Else... time wasted...

As far as changing the licence: The Iceweasel story is a sad example. It lost support completely (IIRC) from Mozilla.

And you don't get geniuses available for some core issues in any complex project just so easily (remember how the https://github.com/minipli/linux-unofficial_grsec/ still hasn't moved passed the specter/meltdown mitigations, geniuses to solve it missing or, being late to do it; if only it is the latter...). Some things about really complex projects, there's only a few people in the world who are able to do it (well, in real time, I mean)...

The support by Moonchild and his team is very close to indispensable. (Especially because we are not huge as Debian.)

I'm on edges. Reloaded that Pale Moon link above a few times only while writing here...

I also asked at:A Pale Moon repo for Devuan/Debianhttps://forum.palemoon.org/viewtopic.ph … 22#p138422I hope this can be worked out. This is a browser that does not impose pulseaudio nor dbus, is fast, and they don't seem to work behind people's back with intrusional purposes.