Yesterday I told people in the Wikiloops Shoutbox that in case they’d need help and none of us moderators is online, they should instead consider to call the Wikiloops Support Line… it’s free, and it’s fun! 🙂
Due to several newly discovered and closed bugs in recent times, it’s advisable to update your browsers, both Firefox and everything based upon Google’s Chrome and Chromium engines.
The fastest of my systems to update these (or their hardened derivates) were DivestOS with updates for their Mull and Mulch browsers, and Arch Linux with the new Firefox and Chromium browsers – thanks for all of your work, it’s really appreciated!
Thanks to you for reading, and for considering to staying safe.
And thanks for everything ladies & gents, and of course to Debra and to Ian!
Update, from Sat 19 Aug (as shown on my monitor): here are some very good reads about Debian, Google’s in-house version of a rolling release Debian, and some message from a no-name-yet variant of it which is about three and a half months older than our daughter. Excellent read, so recommended…
If you’re reading this blog regularly, you might have asked yourselves why all the thoughts about security, privacy, freedom, and so on lately? And you might be one of those who say “I have nothing to hide”. Well…
This one is a must see. It helps if you understand English, French, and German at least a bit, but even if you don’t, watch it to the end:
This comes from the PeerTube, and it promotes those free and decentralised services, and for good reason as you will hear. So please do yourself and us all a favour and stop using Facebook, Whatsapp, and all of that – and replace it with something like Signal or even better, XMPP. We will all profit from it.
Oh, and in case you have an old Android phone which isn’t supported with regular updates anymore, try DivestOS. And if you have a new one from Google, try GrapheneOS (or else, DivestOS again). Sure you can’t live without that intrusive Play Store? Have a look at F-Droid instead. Or are you using Apple instead? Maybe think again… and please start encrypting. You can at least do that even if you stay with a standard Google or Samsung or Apple device.
As always, thanks for reading, and for viewing.
In my recent discussion in one of the GrapheneOS forum threads I was reminded not to encourage people to use that system on devices which aren’t supported anymore, like for instance our Pixel 3a. My follow-up question on how to best preserve such older but perfectly working hardware from becoming landfills, one of the suggestions were that if your tasks don’t really need the highest security, one should probably have a look at DivestOS instead.
And yes, I have read good things about it already, both in the German-speaking blog of Mike Kuketz, and also on the blog of a photographer friend from Florida, US of A. Mike pointed to the About page which states:
DivestOS is a full-time passion project (not a company) maintained solely by Tad (SkewedZeppelin) since 2014. It has many goals, but primarily: prolonging the life-span of discontinued devices, enhancing user privacy, and providing a modest increase of security where/when possible. The devices DivestOS supports are not fully free (as-in-freedom) and there are many security issues we cannot solve such as insecure proprietary blobs, insecure firmware, insecure bootloaders, and insecure ancient kernels. We are also fully aware of our “off-the-rails” approach, however mostly attribute it to the sheer effectiveness provided by “80%” solutions instead of mulling around and not doing anything. We genuinely believe that what DivestOS offers is something unlike any other project, especially with regards to the project scope and our persistence. We hope you find some benefit in our fruits, and remind you to have fun!
And just like the guys from GrapheneOS recommended DivestOS, Tad also writes in the Patch Levely page:
If you want a reasonably secure and well-maintained device, please acquire a newer Pixel (6/6a/7) that is fully supported by GrapheneOS and use it instead.
And that is true. GrapheneOS is probably the most secure system I’ve seen so far, and DivestOS does all they can to provide system updates for devices which aren’t even supported by the hardware vendors (and therefore, also by GrapheneOS) anymore. They even have monthly updates for our 11 year old Google Nexus 10 (Codename “manta”) tablet and its Android version 7 “Nougat”, can you believe that? So it’s this 80% effort Tad writes about which goes a long way, and which helps us all a lot – thanks man!
I’ve made three screenshots of the Pixel 3a running it, still unaltered by me (that came later). Looks like this out of the proverbial box:
So that seems to be the system for older devices. For newer ones, it depends on you or me: stock Android with all its AI goodies like Live Translate from the Google Assistant, or a much more spartan but really more secure GrapheneOS? Only you can decide. At least the Graphene web installer makes it easy in case you want to have a look…
So it’s a big “Thank You!” to people like Daniel and Tad. And like always, thanks to you for reading.
Update, from Sun 20 Aug: here’s an updated version of my home screen on the Google Pixel 3a with DivestOS as the operating system, Lawnchair as an alternative system launcher, itself being updated by Obtainium and directly through GitHub. So it now looks like this:
Themed icons and all, very cool. Almost like a stock Android, but better.
Like always, thanks for viewing, and for reading.
Over in the discussion forum of GrapheneOS, there was an interesting topic, or so I thought, titled: “Brave vs Vanadium“. In it, someone asked about how the Brave browser did seemingly offer better protection against tracking and fingerprinting vs. the hardened Vanadium browser of GrapheneOS, tho this one might be more secure. Some others mentioned tests I hadn’t seen before, so my interest was piqued, I got curious myself, and wanted to see results. So here we go.
First, the Brave browser on my Arch Linux, with a test from fingerprint.com:
Aha. As expected, I saw my IP (that comes from the router, not my machine), the slightly false geolocation (our IPs always resolve way too far East for some reason), and a unique visitor ID. So there’s no “hiding”, trackers and advertisers always know exactly where you are as long as you don’t use VPNs or the onion routing network.
Second test, same browser, with EFF:
And yes, this is where Brave shines in my opinion. Randomized fingerprint plus ads and trackers blocked, that’s what I expected to see.
Third test, also found recently, the real blocking of ads:
Ouch. 72% or 108 of 150 tests blocked, here I expected something better…
Ok, someone in that discussion thread mentioned Edge, so same tests with that one:
Ouch again, this one’s definitely out. A unique fingerprint and no ad and tracker blocking whatsoever, this is one of the worst I’ve seen.
Onto my main operating system and browser of choice, Firefox (with uBlock Origin) on Debian:
Wow, far better than I had expected! A unique fingerprint according to EFF, okay, but that’s probably due to some extensions like WindowSizer and so on… but that it was 10% better than Brave in the real world ad & tracker tests, I must say that I’m impressed!
Ok, now it gets interesting – we’re on a phone operating system’s discussion forum, so let’s take phones into the equation, shan’t we? I have a Google Pixel 6a with stock Android from Google on which I normally use Firefox (also with uBlock Origin), so let’s see:
Cool… we’re down to “nearly unique”, and to 87% blocking of real ads & trackers… the best so far, isn’t it?
Wait, what about Vanadium? That I have on a Pixel 3a with GrapheneOS, so let’s see:
Also strong protection with a nearly unique fingerprint, but these 90% blockings of ads and trackers, that’s what I wanted to see, wow…
Subjectively, I see less ads in other browsers, so I guess I still have to continue reading and understanding it all – but kudos to the team over at GrapheneOS, you did a marvelous job!
As always, thanks for reading.
Update, from August 3rd, in the evening back at home:
Some people in the mentioned discussion forum over at GrapheneOS asked if I had an ad-blocking DNS provider configured in the Vanadium browser on that Pixel 3a phone, and another one asked to please also repeat a test using the Brave browser on a phone instead of a Linux machine.
Point 1: doh… (me silly, mea culpa, and so on) – of course I had set up a more or less secure environment with Graphene on that older Pixel phone, and that included setting up a secure DNS which also uses ad-blocking. So I had to repeat that test, could do it only today as I haven’t been home for a few days. So here you go, with:
Vanadium on GrapheneOS on a Pixel 3a, *without* an ad-blocking DNS configured:
Ouch! 4% block rate only, that wasn’t good… interestingly, with the same secure DNS configured again, at the first try it was raised to about 29 or 30% only, but that could have been session-related I guess; a later test with the browser newly opened went back to the 90% which I had before.
Point 2: the test with Brave on a phone. Did that while I was away, so here you go:
The fingerprint test, as you can see that was from a different location and IP address…
EFF’s Coveryourtracks test again, as good as before, and
The real world blocking test, exactly the same as on the desktop with Arch.
Now the *real* question was/is still unanswered, namely how both would compare under the same conditions, and from mobile phones. So to be fair to the Brave browser, I set up the same ad-blocking secure DNS provider in its settings, et voilà:
95%, and only 7 of the 150 tested “attacks” left unblocked, that’s the top position of my tests so far.
So how to answer that initial question about which one to choose? Hard to say, maybe I will install and leave both on that Pixel 3a with GrapheneOS, for me Vanadium will most likely always stay the default browser on Graphene (and its web view part anyway), but I will further test Brave when in doubt, or when I see something unusual and/or new.
I’m sorry that my first test attempt was a bit misleading, and I hope this additional one could clear up things a bit? In any case, and as usual, thanks very much for reading.
He wrote it yesterday according to his blog post entry date, but I’ve found it today. And because it’s just four lines in my browser, instead of citing him here, I’ll give you Bill’s link to what I consider the quote of the day for today…
Beautiful. Thanks Bill.
My computer normally runs with a 48000Hz sampling rate for audio, that’s the one you would also use for most video productions like when producing something for the ‘tubes and such.
But CDs had 44100Hz which is also perfectly fine, and which saves some space if you record with that frequency – and so some (or even most?) of my friends over at Wikiloops use that sampling rate for their music.
No problem; Ardour checks when importing, and would normally automatically convert the imported 44.1kHz files to 48kHz ones. But that would mean that I’d make it harder for others who would probably like to add my single tracks to the rest (with 44.1Khz). And also, each conversion diminishes the quality just a tiny bit, so it’s always best if/when you can avoid these and use the material as it comes. Even Ardour says so:
But how to temporarily set Ardour to 44.1kHz? Easy in case you’re using the new pipewire! I just wrote the following short shell script which I named ‘ardour44k.sh’:
pw-metadata -n settings 0 clock.force-rate 44100 PIPEWIRE_LATENCY=128/44100 pw-jack ardour wait pw-metadata -n settings 0 clock.force-rate 0
So if I start Ardour using that, I can use 44100Hz just perfectly fine – and when Ardour ends, the system will be set back to 48000Hz; just what I wanted. Here are some screenshots from Ardour’s Edit and Mixer windows while it ran with 44100Hz:
And when I stop Ardour, the script ends with:
set property: id:0 key:clock.force-rate value:0 type:(null)
Oh, and what I’m also using with pipewire (which is now the standard audio “engine” on Debian and most other Linux distributions) is a program called qpwgraph, and that is a graphical patchbay like the older tools (qjackctl, Carla, Catia & Co). Looks like this:
Here you see three inputs for my upright bass on the left, which go into Ardour. The right side shows Ardour’s monitor section and its metronome going out into my sound interface, and from there, into my headphones. The outputs of individual tracks go back into Ardour’s master track, which gives you this figure 8 shape. Easy peasy, isn’t it? Virtual cabling, so to say…
Thanks to you for reading.
Not too long ago I took a photo with using the “grainy film 2” filter of my Olympus camera, directly in-camera, pre-“shot”. And I thought that it didn’t look too bad, so today I played around with a photo of myself which my former colleague Gunther took of me after I had set up lights to take/make portraits of some of these colleagues. So I re-“developed” the photo from the raw image using that filter, and afterwards I adjusted both the luminance and the contrast a bit, “to taste” as they say. And here’s the result of that photo from July 24th, 2018:
Thanks Gunther for taking my photo, thanks to the Fediverse for storing it ( on the small server where you can find me @email@example.com ) – and as always, thanks for reading and for viewing.