It looks like Meta already allows bad actors on its instance: https://kolektiva.social/@ophiocephalic/110667668701596654

The good: familiar UI, nice community

The bad: much worse accessibility.

Conclusion: I'd recommend keeping a Gitea/Codeberg remote but not using it exclusively. Doing so should include more people without excluding people who use assistive technology.

Unfortunately, Gitea (the forge software that powers Codeberg) has major accessibility issues. It's not usable from most assistive technologies (e.g. screen readers). GitLab isn't much better.

Sourcehut is pretty much the only GitHub alternative with good accessibility I know of.

This is their privacy policy: https://h5hosting-dra.dbankcdn.com/cch5/petalsearch/global/agreement/privacy-statement.htm?language=en-us

It includes detailed fingerprinting metrics like mouse behavior and font information.

I should probably link it, thanks for the feedback.

I said that about Petal because readers likely hadn't heard of it and didn't have any expectations. l assume readers already knew Bing, Google, and Yandex were bad for privacy.

Not at all; there are tons of newish engines out there, the best of which are trying to carve out a niche for themselves in an area that Google and Bing ignore. I listed 44 English engines with their own indexes, along with some for other languages which I'm unfortunately unable to review because I don't speak the langs required.

On these engines, you won't get far if you use natural language queries or expect the engine to make inferences. Use broad terms and keywords instead. I recommend giving Mojeek, Marginalia, Teclis, Petal (bad privacy, but usable through Searx), Kagi, and Alexandria a try.

In these discussions, it's worth distinguishing between "reducing the size of your fingerprint" (reducing data collection, e.g. by blocking trackers) and "reducing the likelihood of connecting your footprint to an identity" (fingerprinting avoidance). Customization, extensions, adblocking, etc. are antithetical to the latter but useful to the former.

The reality is more nuanced than this. Wrote up my thoughts on my blog: A layered approach to content blocking.

Strictly speaking about content filtering: declarativeNetRequest is honestly a good thing for like 80% of websites. But there's that 20% that'll need privileged extensions. Content blocking should use a layered approach that lets users selectively enable a more privileged layer. Chromium will instead be axing the APIs required for that privileged layer; Firefox's permission system is too coarse to support a layered approach.

I agree about Brave which is why I said I'd like to see a fork that removes all the cryptocurrency nonsense.

I think that among the indie crowd (not large orgs/corps) the best we can do is test our sites in other non-mainstream engines and stick to standards. The SerenityOS browser, Servo, and NetSurf are cirrently maintained; there's also KHTML, Hv3, etc. Supporting one or two fully independent options in addition to the big three could go a long way.

Funny that I just noticed this here, right after I posted my own thoughts on the matter: https://lemmy.ml/post/308999

TLDR: Mv3's declarativeNetRequest is a really good replacement for a subset of uBlock Origin's functionality. If it didn't herald an end to privileged extensions then I'd welcome it. But Google gotta Google; can't take one step forward without two steps back.

There are some valid reasons to use Blink; for those use-cases, I'd love to see a "de-Braved-Brave" fork of Brave that removes all the "cryptography-verified, decentralized pyramid scheme" nonsense but keeps the great content blocking.

If you're asking for an open-source option because you want to self-host...well, at that point, you'd already have a web server. Just sftp/rsync the files over into a subdir of your web root.

If you're concerned about your browser "phoning home", you can find out exactly what it's chattering about using key logs and a packet sniffer (I recommend Wireshark or derivatives). Key logs are required for decrypting TLS traffic, and Firefox + Chromium support them.

The safety of TUI browsers is a bit overrated; most don't do any sandboxing of content whatsoever and are run in an unsandboxed environment. Both of these are important for a piece of software that only exists to parse untrusted content from the most hostile environment known (the Web).

Check a CVE database mirror for your favorite TUI browser; if it has a nontrivial number of users, it'll have some vulns to its name. Especially noteworthy is Elinks, which I absolutely don't recommend using.

Personally: to read webpage from the terminal, I pipe curl or rdrview output into w3m that's sandboxed using bubblewrap (bwrap(1)); I wrote this script to simplify it. I use that script to preview HTML emails as well. The sandboxed w3m is forbidden from performing a variety of tasks, including connecting to the network; curl handles that.

Tangential: rdrview is a CLI tool that implements Mozilla's Readability algorithm. It uses libseccomp for sandboxing on Linux and Pledge to do so on OpenBSD. Piping its HTML output into w3m-sandbox makes for a great text-extraction workflow.

The problem is that your offline CA stores won't use OCSP revocation logs or certificate transparency. You need live updates for those. The latter is especially important, as without it you're completely dependent on one group of CAs.

I compiled a list of search engines that use their own indexes for organic results: https://seirdy.one/2021/03/10/search-engines-with-own-indexes.html

I'll probably post a big update to that article at some point that compares if/how some of the listed engines process structured data (RDFa, microdata, JSON-LD, microformats 1/2, open graph metadata, POSH).

I typically use a Searx/SearxNG instance that mixes Google, Bing, and Bing-derivatives (e.g. DDG) with other indexes: Petal, Mojeek, Gigablast, and Qwant (Qwant mixes its own results with Bing's). Petal, Gigablast, and Mojeek have been quite helpful for discovering new content; however, I wouldn't use Petal directly due to privacy concerns. Using it through a Searx proxy you trust more seems alright.

If I know a query will give me an instant answer I want to use, I'll use DDG.

Not just this thread, but the rest of Fedi, IRC, my own email, and Matrix too. My posts get atl 20% longer after I share them.

Servers use Linux

The server, desktop, and mobile computing models are all quite different. The traditional desktop model involves giving programs the same user privileges and giving them free reign over all a user’s data; the server model splits programs into different unprivileged users isolated from each other, with one admin account configuring everything; the mobile model gives programs private storage and ensures that programs can’t read each others’ data and need permission to read shared storage. Each has unique tradeoffs.

macOS has been adopting safeguards to sandbox programs with fewer privileges than what's available to a user account; Windows has been lagging behind but has made some progress (I'm less familiar with the Windows side of this). On Linux, all modern user-friendly attempts to bring sandboxing to the desktop (Flatpak and Snap are what I'm thinking of) allow programs opt into sandboxing. The OS doesn't force all programs to run with minimum privileges by default having users control escalating user-level privileges; if you chmod +x a file, it gets all user-level privileges by default. Windows is...somewhat similar in this regard, I admit. But Windows' sandboxing options--UXP and the Windows Sandbox--are more airtight than Flatpak (I'm more familiar with Flatpak than Snap, as I have some unrelated fundamental disagreements with Snap's design).

I think Flatpak has the potential to improve a lot: it can make existing permissions enabled at run-time so that filesystem-wide sandboxing only gets enabled when a program tries to bypass a portal (most of the "filesystem=*" apps can work well without it, and some only need it for certain tasks), and the current seccomp filter can be made a "privileged execution" permission with the default filters offering fine-grained ioctl filtering and toggleable W^X + W!->X enforcement. The versions of JavaScriptCore, GJS, Electron, Java, and LuaJIT used by runtimes and apps can be patched to run in JITless mode unless e.g. an envvar for "privileged execution" is detected. I've voiced some of these suggestions to the devs before.

My favorite (and current) distro is Fedora. If Flatpak makes these improvements, Fedora lands FS-verity in Fedora 37, Fedora lands dm-verity in Silverblue/Kinoite, and we get some implementation of verified boot that actually lets users control the signing key: I personally wouldn't consider Fedora "insecure" anymore. Though I'd still find it to be a bit problematic because of Systemd. I wasn't convinced by Madaidan's brief criticisms of Systemd; I prefer this series of posts that outlines issues in Systemd's design and shows how past exploits could have been proactively (instead of reactively) avoided:

• https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet
• https://www.agwa.name/blog/post/systemd_is_not_magic_security_dust
• https://www.agwa.name/blog/post/thoughts_on_the_systemd_root_exploit

Systemd exposes nice functionality and I genuinely enjoy using it, but its underlying architecture doesn't provide a lot of protections against itself. The reason I bring it up when distros like Alpine and Gentoo exist is that the distro I currently think best combines the traditional desktop model with some hardening--Fedora Silverblue/Kinoite--uses it.

QubesOS is based on Linux

QubesOS is based on Linux, but it isn't in the same category as a traditional desktop Linux distribution. Like Android and ChromeOS, it significantly alters the desktop model by compartmentalizing everything into Xen hypervisors. I brought it up to show how it's possible to "make Linux secure" but in doing so you'd deviate heavily from a standard distribution. Although Qubes is based on Linux, its devs feel more comfortable calling it a "Xen distribution" to highlight its differences from other Linux distributions.

Here’s an exhaustive list of the proprietary software on my machine:

This is a defeatist attitude and meaningless excuse.

I only brought this up in response to the bad-faith argument you previously made:

I think you have gotten influenced by madaidan’s grift because you use a lot of closed source tools and want to justify it to yourself as safe.

I don't use any closed-sourced tools on my personal machine beyone hardware support, emulated games, and webapps I have to run for online classes. Since you seem to be arguing in bad faith, I don't think I'll engage further. Best of luck.

He is a security grifter that recommends Windows and MacOS over Linux for some twisted security purposes.

Windows Enterprise and macOS are ahead of Linux's exploit mitigations. Madaidan wasn't claiming that Windows and macOS are the right OSes for you, or that Linux is too insecure for it to be a good fit for your threat model; he was only claiming that Windows and macOS have stronger defenses available.

QubesOS would definitely give Windows and macOS a run for their money, if you use it correctly. Ultimately, Fuchsia is probably going to eat their lunch security-wise; its capabilities system is incredibly well done and its controls over dynamic code execution put it even ahead of Android. I'd be interested in seeing Zircon- or Fuchsia-based distros in the future.

When it comes to privacy: I fully agree that the default settings of Windows, macOS, Chrome, and others are really bad. And I don't think "but it's configurable" excuses them: https://pleroma.envs.net/notice/AB6w0HTyU9KiUX7dsu

I think you have gotten influenced by madaidan’s grift because you use a lot of closed source tools and want to justify it to yourself as safe.

Here's an exhaustive list of the proprietary software on my machine:

• Microcode
• Intel subsystems for my processor (ME, AMT is disabled. My next CPU hopefully won't be x86_64 because the research I did on ME and AMD Secure Technology gave me nightmares).
• Non-executable firmware
• Patent-encumbered media codecs with open-source implementations (AVC/H.264, HEVC/H.265). This should be FLOSS but algorithms are patented; commercial use and distribution can be subject to royalties.
• Web apps I'm required to use and would rather avoid (e.g. the web version of Zoom for school).
• Some Nintendo 3DS games I play in a FLOSS emulator (Citra). Sandboxed, ofc.

That's it. I don't even have proprietary drivers. I'm strongly against proprietary software on ideological grounds. If you want to know more about my setup, I've made my dotfiles available.

And… you cannot study the closed source software.

Sure you can. I went over several example.

I freely admit that this leaves you dependent on a vendor for fixes, and that certain vendors like oracle can be horrible to work with (seriously check out that link, it's hilarious). My previous articles on FLOSS being an important mitigation against user domestication are relevant here.

Can you, with complete certainty, confidently assert the closed source software is more secure? How is it secure? Is it also a piece of software not invading your privacy? Security is not the origin of privacy, and security is not merely regarding its own resilience as standalone code to resist break-in attempts. This whole thing is not just a simple two way relation, but more like a magnetic field generated by a magnet itself. I am sure you understand that.

I can't confidently assert anything with complete certainty regardless of source model, and you shouldn't trust anyone who says they can.

I can somewhat confidently say that, for instance, Google Chrome (Google's proprietary browser based on the open-source Chromium) is more secure than most Webkit2GTK browsers. The vast majority of Webkit2gtk-based browsers don't even fully enable enable sandboxing (webkit_web_context_set_sandbox_enabled).

I can even more confidently say that Google Chrome is more secure than Pale Moon. In fact, most browsers are more secure than Pale Moon.

To determine if a piece of software invades privacy, see if it phones home. Use something like Wireshark to inspect what it sends. Web browsers make it easy to save key logs to decrypt packets. Don't stop there; there are other techniques I mentioned to work out the edge cases. A great option is using a decompiler.

Certain forms of security are necessary for certain levels of privacy. Other forms of security are less relevant for certain levels of privacy, depending on your threat model. There's a bit of a venn-diagram effect going on here.

FLOSS being less secure when analysed with whitebox methods assures where it stands on security.

Sure, but don't stop at whitebox methods. You should use black-box methods too. I outlined why in the article and used a Linux vuln as a prototypical example.

This will always be untrue for closed source software, therefore the assertation that closed source software is more secure, is itself uncertain.

You're making a lot of blanket, absolute statements. Closed-source software can be analyzed, and I described how to do it. This is more true for closed-source software that documents its architecture; such documentation can then be tested.

Moreover, FOSS devs are idealistic and generally have good moral inclinations towards the community and in the wild there are hardly observations that tell FOSS devs have been out there maliciously sitting with honeypots and mousetraps. This has long been untrue for closed source devs, where only a handful examples exist where closed source software devs have been against end user exploitation. (Some common examples in Android I see are Rikka Apps (AppOps), Glasswire, MiXplorer, Wavelet, many XDA apps, Bouncer, Nova Launcher, SD Maid, emulators vetted at r/emulation.)

I am in full agreement with this paragraph. There is a mind-numbing amount of proprietary shitware out there. That's why, even if I was only interested in security, I wouldn't consider running proprietary software that hasn't been researched.

Yep. Foot is Wayland-only

I should add that Alacritty running with X11 compatibility isn't quite as fast as running it on Wayland. Both Alacritty and Foot can utilize Wayland's excellent frame timing/vsync support to prioritize rendering only when the display refreshes. Doing so reduces load (esp. in Alacritty's case since it can offload most work to the GPU), which is sorely needed because proper font rendering is an intensive process to do in a latency-sensitive manner.

I am tired of people acting like blackbox analysis is same as whitebox analysis.

I was very explicit that the two types of analysis are not the same. I repeatedly explained the merits of source code, and the limitations of black-box analysis. I also devoted an entire section to make an example of Intel ME because it showed both the strengths and the limitations of dynamic analysis and binary analysis.

My point was only that people can study proprietary software, and vulnerability discovery (beyond low-hanging fruit typically caught by e.g. static code analysis) is slanted towards black-box approaches. We should conclude that software is secure through study, not by checking the source model.

Edit: I liked that last sentence I wrote so I added it to the conclusion. Diff.

Lots of FLOSS is less secure than proprietary counterparts, and vice versa. The difference is that proprietary counterparts make us entirely dependent on the vendor for most things, including security. I wrote two articles exploring that issue, both of which I linked near the top. I think you might like them ;).

Now, if a piece of proprietary software doesn't document its architecture, makes heavy use of obfuscation techniques in critical places, and is very large/complex: I'd be very unlikely to consider it secure enough for most purposes.

You're not the first person to ask, which is why I updated the post to expand the acronym in the first sentence. Diff.

You make a lot of good points here, many of which I actually agree with.

The article focused on studying the behavior and properties of software. For completeness, it mentioned how patching can be crowdsourced with the example of Calibre. I also described how FLOSS decreases dependence on a vendor, and wrote two prior posts about this linked at the top.

I never claimed that source code is useless, only that we shouldn't assume the worst if it isn't provided.

@X_Cli@lemmy.ml I updated the post to add a bit to one of the counter args, with a link to your comment. Here's a diff

Linters are a great thing I should've mentioned, esp. ones like ShellCheck. The phrase "low-hanging fruit" has been doing a lot of heavy lifting. I should mention that.

I talked a lot about how to determine if software is insecure, but didn't spend enough time describing how to tell if software is secure. The latter typically involves understanding software architecture, which can be done by documenting it and having reverse engineers/pentesters verify those docs' claims.

It's getting late (UTC-0800) so I think I'll edit the article tomorrow morning. Thanks for the feedback.

Advanced font fallback is one of the defining features of the Foot terminal, if you're interested. You can even specify different fonts, which is useful for e.g. getting emojis to fit in one cell.

Check out the removeparam and redirect directives in the static filter syntax docs.

GitHub is both (proprietary) software and a service. The main product is the service, and the software is just a means to that.

The service consists of SaaS and/or paid support. They sell at least one of these to the military and/or ICE.

If GitLab or Sourcehut did something similar, the same would apply even those are open-core and FLOSS, respectively.

Given the attack surface of addons, I've downsized my addon usage.

• I've replaced HTTPS-Everywhere with the built-in HTTPS-first/only modes in FF and Chromium.

• In FF, I use userContent.css instead of Stylus.

• I use uBlock Origin's url-rewriting filters in place of redirection addons.

• In Chromium, you can choose to have an addon only be enabled on certain sites. I do this with Stylus and Dark Background Light Text.

EDIT: more information:

• I have a shell script that uses regex to "clean" urls in the clipboard and remove tracking params instead of the CleanURLs addon, since this is most useful when sharing links with others. I've gotten in the habit of previewing URL content before navigation (e.g. with a mouseover or by pasting into the URL bar) as well. If I want to navigate to a messy url, I just copy it and enter a keybind to clean the copied URL.

I use multiple browsers and profiles.

• Normal browsers: Firefox with Cookie Autodelete, uBO, Stylus, Dark Background and Light Text; Chromium with uBO and Stylus. Stylus is only selective enabled.

• For security-sensitive non-anonymous stuff, I run Chromium with flags to disable JIT and to disable JS by default, in a bubblewrap sandbox. This browser profile has no addons.

• For peak anonymity (e.g. when using one of my anon alts), I run the Tor Browser in a Whonix VM. For quick anonymity I just use the regular Tor Browser Bundle in a bubblewrap sandbox. In an act of mercy towards my weak 2013 Haswell laptop's battery, I no longer run Qubes. The Tor Browser should not ever be used with custom addons if you want anonymity.

Because the Tor browser should never run with addons and because I use a browser profile that has none, I don't want addons to be a "crutch" that I depend on too much.

I do global hostname-blocking at the DNS level, so I can live without an adblocker. DNS blocking doesn't do fine-grained subpage-blocking, conditional blocks, cosmetic filtering, redirects, etc. so a more complete solution is still worthwhile.

I also try to avoid injecting content into webpages with JS enabled, since that is extremely fingerprintable and opens a can of (in)security worms.

Some addons that I do not recommend at all:

• Canvas Fingerprinting Defender: injects JS into pages, which is very fingerprintable and can trigger a CSP report if you don't disable those. CSP reports can identify you even if you disable JS execution.

• Anything that you can do without an addon, TBH. They do weaken the browser security model.

I prefer the previous version, but this works too.

A recent article on Corporate Memphis: Why does every advert look the same? Corporate Memphis.

Its popularity is the result of a feedback loop: it's popular because it's popular. It also makes people feel safe and comfortable (a form of brain-hacking, if you will).

Honestly, I wouldn't mind it too much if it wasn't so overused. Now I immediately feel distrustful the second I see it. It makes me assume that I'm looking at a page made by an advertiser rather than something honest. Product information shouldn't try to make me feel something, it should tell me why I should and shouldn't use something.

Unfortunately, lots of people used it because it had Google's logo which made it much easier for management to get on-board. Re-writing the entire frontend while including all the user-hostile trackers/ads is a harder sell for the decision-makers.

In other words, AMP is faster and easy to convince your boss' boss to use. Regular sane websites with a different CDN are even faster but less convincing.

Some of these sites are also trying to optimize their Core Web Vitals, and Amp makes it easier to do this. It's far from the optimal way, though.

I personally don't have a problem with pages loading more honestly and taking a second or two to send the first byte from a server across the world if it means less dependence on corps with enough money to build global CDN networks. In addition to giving Google more control of the Web, which is problematic enough, AMP seems targeted mostly towards the "corporate" web.

I agree that the PR process is bureaucratic, but that's not the workflow that Git was made for. It's a workflow popularized by GitHub.

The workflow that Git was made for was "make commits" + "export patches" + "send patches". This typically happens over a mailing list. Under this workflow, sending a contribution is a two-step process: git commit and git send-email. The recipient could be a mailing list, or it could just be the developer's email address you grabbed from a commit message. That's part of the reason why Git has you include your email in every commit.

IRC diehard checking in. I prefer IRC to Matrix (been using both daily for a year or two now), but a switch wouldn't be the end of the world.

Matrix has a high and growing complexity that makes developing a new client/server hard; as the spec grows, devs need to keep updating servers/clients with new features or risk being left behind. IRC clients can be whipped up by an individual in a short amount of time and then enter "maintenance mode".

System requirements for running a Matrix server are extremely high with Synapse, and not that great with Dendrite and Conduit compared to most IRC implementations because of the need to sync room histories.

Matrix also has a lot of features that I've come to find unnecessary/distracting: typing notifications, stickers, profile pics, etc. It's possible to carve out a subset of the protocol and just use that, but at that point it's probably better to just use IRC.

Google AMP isn't dead, it's just not given preferential treatment in Google search anymore.

Yandex also has an equivalent technology called Turbo Pages; I'm not sure if Yandex has preferential treatment for that ATM.

I think both are awful and can be replaced by plain HTML/CSS 90% of the time.

My enterprise-grade notes setup:

mkdir ~/Documents/Notes
cd ~/Documents/Notes
$EDITOR name_of_note.txt

For lecture notes, I do this:

$EDITOR "$(date +'%Y-%m-%dT%H:%M:%S%:z').md"

I don't actually type out commands like these; I have alises for them. I sync my notes with git, so I don't have to learn another tool just for notes.

I updated the "What explicitly opting out actually entails" section to further elaborate on why adding this header might not really improve user privacy.

Server side categorization for sites with ads is where this Permissions action is aimed at. What this is saying is that if an ad tries to get a cohort id from an opted-out site, it will receive a meaningless default value. This knowledge is for the benefit of advertisers, not webmasters.

The solution is not to include trackers on your page in the first place, such as third-party ads. Permissions-Policy applies to the page requested and its contents.

As for cohort calculation, things are messy. If one site is opted out and another consequently has a greater weight, the implications wrt. fingerprinting are vague. Opting out doesn't necessarily reduce a user's fingerprint. FLOSS is one aspect of a user's interests, but there are countless others. There is/was no legal or technical obligation to obey either the DNT header or this permissions-policy header (strictly for the purposes of cohort calculation), since the latter isn't standard usage of the permissions-policy header and the former isn't even a standard header in the first place.

A coordinated effort is better spent getting users off Chrome than getting upstream software and webmasters to add this band-aid to their sites.

I updated the article to explicitly address this; check the "What explicitly opting out actually entails" section.

I wrote about both issues, and why Matrix isn't a perfect solution, previously: part 1, part 2. Starring WhatsApp, Firefox, Signal, XMPP, Email, and Matrix.

Also discussed on Lemmy: part 1, part 2.

Signal's problem is being a closed platform; Matrix suffers primarily from complexity. Both enable dependence on a single small group, and therefore enable user domestication. That being said, Matrix is considerably less bad than Signal.

For large public rooms, IRC continues to be the best option. All its issues are client-side; IRCv3 supports history, multiple devices, authentication without NickServ, and even typing notifications. All these features are supported on Oragono. For small, private E2EE rooms, all existing solutions have major trade-offs.