In search of a privacy oriented browser

astheroth · 2018-09-02 00:24:45

Otter browser would be a good option. It's floss and on qt5, but it's required to compile it and install from source, since there is no .deb package.
https://otter-browser.org/

chris2be8 · 2018-09-02 19:30:22

I've tried the version of chromium in Synaptic, it looks to be googled in that it keeps suggesting I sign on to google services.

But I'm not intending to use it. It's obviously designed to be mouse driven and lacks keyboard shortcuts. Which makes it very annoying when used with a full size keyboard in front of me and the mouse off to one side. At least in Konqueror I can press alt-B for bookmarks etc without needing to take my hands off the keyboard. All it needs is a cache to make it do all I want from a browser.

Chris

PS. iceweasel was a fork of firefox, it's been folded back now, the version in Synaptic would be firefox in all but name.

siva · 2018-09-13 17:42:02

ungoogled chrome: iridium (preferred); chromium (backup)

firefox: waterfox (preferred); esr (backup); quantum (work pc)

minimal: surf2 (preferred webkit); w3m (preferred if I'm working in a GUI-less environment)

I prefer firefox/waterfox with the following: ublock origin, umatrix, canvasblocker, shape-shifter, privacy settings, decentraleyes, WebRTC Blocker, and smartreferer (although I think uBo and umatrix have similar settings). You can also install these on Android Firefox/Fennec F-Droid.

Edit: true privacy online is really a deep conundrum. You'll probably want to study some networking concepts and methods outside of the scope of your browser alone.

Last edited by siva (2018-09-13 17:43:08)

UnclePa · 2018-09-14 20:59:57

Thanks everyone! While it worked fairly well, brave was a huge memory hog and it had some shortcomings. I've been running ungoogled chrome for a couple of days now and think it may be just what I was looking for. I have more tabs open than I did with brave and using 5GB less memory but that's not quite a fair comparison until I've used it a few more days.

dxrobertson · 2018-09-14 22:23:38

Not for everyday use, but when I need to, for example; blow through a news site limited access, links2 works wonders. I suspect its ability to access around their front-wall limits are its "not fully functional" style sheeting and javascript. This lack of full functionality also should aid in security and anonymity.

This doesnt exactly address your original post, but when you need to access a certain site you want to exercise extra caution, links2 may be best.

wget is another option, but requires a little more work to view the content.

siva · 2018-09-15 01:11:54

Yeah I'm not sure if Ungoogled Chrome is the gold-tier for privacy, but if that's what works for you...

@dx: you're absolutely right. It's a shame that javascript is becoming a new "norm."

ChuangTzu · 2018-09-15 22:12:00

regarding Iridium browser, FYI
https://news.ycombinator.com/item?id=9482689

miroR · 2018-09-18 11:31:55

astheroth wrote:

Otter browser would be a good option. It's floss and on qt5, but it's required to compile it and install from source, since there is no .deb package.
https://otter-browser.org/

I'm currently using Pale Moon, and it works fine. My own build, from Steve Pusser's repo. There are topics on Pale Moon forums, if anybody is interested.

But Otter browser would supply one of the requirements for me: sans-dbus, for which see:
Refracta no-dbus experiment
https://dev1galaxy.org/viewtopic.php?id=2158#p11846

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?

And then (currently on
https://github.com/OtterBrowser/otter-browser ):

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.

(but I haven't reproduced all the links of the text)

And, I have:

# apt-cache policy openssl
openssl:
  Installed: 1.1.0h-4
  Candidate: 1.1.0h-4
  Version table:
 *** 1.1.0h-4 500
        500 tor+http://devuanfwojg73k6r.onion/merged testing/main amd64 Packages
        100 /var/lib/dpkg/status

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?

Regards!

Last edited by miroR (2018-09-18 11:48:44)

miroR · 2018-09-18 12:22:31

ChuangTzu wrote:

regarding Iridium browser, FYI
https://news.ycombinator.com/item?id=9482689

An interested read.

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 ?

Are packages from:
https://iridiumbrowser.de/downloads/debian
D-Bus free?
UPDATE/CORRECTION: I really meant: are they available for installing in a dbus-free system? Sorry.

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

Last edited by miroR (2018-09-18 12:34:13)

siva · 2018-09-18 16:31:00

miroR wrote:

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...?
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/history
That'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.

miroR · 2018-09-18 22:11:58

siva wrote:

miroR wrote:
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/history
That'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.

Also I noticed at https://iridiumbrowser.de/downloads/debian:
Currently, this is how they recommend doing it:

wget -qO - https://downloads.iridiumbrowser.de/ubuntu/iridium-release-sign-01.pub|sudo apt-key add -
cat <<EOF | sudo tee /etc/apt/sources.list.d/iridium-browser.list
deb [arch=amd64] https://downloads.iridiumbrowser.de/deb/ stable main
#deb-src https://downloads.iridiumbrowser.de/deb/ stable main
EOF
sudo apt-get update
sudo apt-get install iridium-browser

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 Moon
https://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.

I suppose Iridium can be installed w/o D-Bus, can it?

Pity I'm very short on time for probably a few days...

Regards!

msi · 2018-09-19 16:23:31

miroR wrote:

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.

miroR wrote:

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.
(but I haven't reproduced all the links of the text)
And, I have:
# apt-cache policy openssl
openssl:
  Installed: 1.1.0h-4
  Candidate: 1.1.0h-4
  Version table:
 *** 1.1.0h-4 500
        500 tor+http://devuanfwojg73k6r.onion/merged testing/main amd64 Packages
        100 /var/lib/dpkg/status
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.)

miroR wrote:

But why are there no Debian packages?

One reason is probably that, up to now, the project has only published release candidates.

On a non-privacy-related side note: Otter also doesn't depend on Pulseaudio.

Last edited by msi (2018-09-19 16:29:30)

chris2be8 · 2018-09-19 16:58:02

See https://www.schneier.com/blog/archives/ … o_tra.html for details of a big hole in most browsers cookei handling.

Chris

miroR · 2018-09-20 16:00:07

msi wrote:

miroR wrote:
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.)

Not a problem in testing (beowulf] that I run:

# apt-cache policy libqt5core5a
libqt5core5a:
  Installed: 5.11.1+dfsg-8
  Candidate: 5.11.1+dfsg-8
  Version table:
 *** 5.11.1+dfsg-8 500
        500 tor+http://devuanfwojg73k6r.onion/merged testing/main amd64 Packages
        100 /var/lib/dpkg/status

miroR wrote:
But why are there no Debian packages?
One reason is probably that, up to now, the project has only published release candidates.
On a non-privacy-related side note: Otter also doesn't depend on Pulseaudio.

Great to know ! Thanks!

Last edited by miroR (2018-09-20 16:00:49)

miroR · 2018-09-20 16:08:53

chris2be8 wrote:

See https://www.schneier.com/blog/archives/ … o_tra.html for details of a big hole in most browsers cookei handling.
Chris

I opened it up. Will read it offline. But, speaking of Bruce Schneier, there was an opportunity to buy non-DRM e-books of his
Three of My Books Are Available in DRM-Free E-Book Format
https://www.schneier.com/blog/archives/ … y_boo.html :

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...

Last edited by miroR (2018-09-20 16:55:54)

siva · 2018-09-24 02:09:25

It's stock iridium on openbsd, but you get the idea.

https://ibb.co/kc1AU9

If anyone wants to run something a little more sophisticated than tcptrack, I'm all eyes. All of this further disincentivizes me from using chrome-like browsers for any reason.

miroR · 2018-09-24 07:51:38

In view of:

siva wrote:

It's stock iridium on openbsd, but you get the idea.
https://ibb.co/kc1AU9
If anyone wants to run something a little more sophisticated than tcptrack, I'm all eyes. All of this further disincentivizes me from using chrome-like browsers for any reason.

What tcptrack is doing appears to me just one aspect of the deep packet analysis. E.g., it isn't extracting streams nor HTTP payload such as files as the browser gets them, nor, most importantly, decrypting SSL... But I may be wrong, as I judge from only what https://duckduckgo.com gave me:
https://duckduckgo.com/?q=tcptrack&t=h_&ia=web

tcptrack
Software
Tcptrack 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
http://freshmeat.net/projects/tcptrack

So for aspects of the network analysis (stress is on some), even my scripts are much more useful... But I guess it's great for real time look into what is exactly now happening...

I think I should reply to the older post from siva.

siva wrote:

miroR wrote:
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...?

I didn't get what you mean when I glossed over it the first time... Also, time was and still is in short supply here...

This, and apparently --thing is, I'm still not into Iridium, no time found yet for it, so I can't state anything for certain here-- that's an Iridium dev talking there.

Let me paste it, it's from over at that same link ( https://news.ycombinator.com/item?id=9482689 ):

...
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.

Last edited by miroR (2018-09-24 07:52:11)

siva · 2018-09-24 14:39:04

miroR wrote:

...for aspects of the network analysis (stress is on some), even my scripts are much more useful... But I guess it's great for real time look into what is exactly now happening...

Correct. The idea was to verify that it is reaching out to its home servers. Running a simple "whois" on the IP addresses in my screenshot should confirm, as should visiting 88.198.85.193.

...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. 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.

miroR · 2018-09-25 18:11:38

siva wrote:

(quote by Iridium developer:)
miro wrote:
...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!

The officially official Devuan Forum!

#26 2018-09-02 00:24:45

Re: In search of a privacy oriented browser

#27 2018-09-02 19:30:22

Re: In search of a privacy oriented browser

#28 2018-09-13 17:42:02

Re: In search of a privacy oriented browser

#29 2018-09-14 20:59:57

Re: In search of a privacy oriented browser

#30 2018-09-14 22:23:38

Re: In search of a privacy oriented browser

#31 2018-09-15 01:11:54

Re: In search of a privacy oriented browser

#32 2018-09-15 22:12:00

Re: In search of a privacy oriented browser

#33 2018-09-18 11:31:55

Re: In search of a privacy oriented browser

#34 2018-09-18 12:22:31

Re: In search of a privacy oriented browser

#35 2018-09-18 16:31:00

Re: In search of a privacy oriented browser

#36 2018-09-18 22:11:58

Re: In search of a privacy oriented browser

#37 2018-09-19 16:23:31

Re: In search of a privacy oriented browser

#38 2018-09-19 16:58:02

Re: In search of a privacy oriented browser

#39 2018-09-20 16:00:07

Re: In search of a privacy oriented browser

#40 2018-09-20 16:08:53

Re: In search of a privacy oriented browser

#41 2018-09-24 02:09:25

Re: In search of a privacy oriented browser

#42 2018-09-24 07:51:38

Re: In search of a privacy oriented browser

#43 2018-09-24 14:39:04

Re: In search of a privacy oriented browser

#44 2018-09-25 18:11:38

Re: In search of a privacy oriented browser

Board footer