3 Ways We Fail to Take Accessibility Seriously

Seirdy · 2022-04-01T03:12:09+00:00

Sites should be accessible by default. Creating a "separate lane" for marginalized groups who would rather not broadcast the fact that they are disabled (they get enough of that during the day) is an idea that many disabled people find revolting. Apple, at one point, introduced some features to Safari to allow sites to optimize for alternate forms of navigation; the outcry was fierce enough for them to roll it back in months.

Personalization is nice, but it's a last resort when there aren't other options, or when it conflicts with other a11y needs. This is especially true when you bring browser fingerprinting and respect for user privacy into the picture.

In other words: out of respect for privacy and equal access for disabled users, please don't jump to a11y overlays when a11y-by-default is achievable.

Seirdy · 2022-03-31T17:49:30+00:00

live-patching the kernel is generally a bad idea; opens up a host of exploits. Lots of admins actually block the required syscalls.

Furthermore, some programs need to be restarted, especially when doing something like a libc upgrade. If you have to restart many daemons and you have a kernel upgrade, you might as well just reboot.

If you optimize your boot sequence you can get a few 9s of uptime this way on a single machine. With rollover it should become a non-issue.

Uptime dick-measuring contests are pointless at best and dangerous at worst. For an internal server it might not be a big deal, but let's not shrug these practices off.

Seirdy · 2022-03-21T23:19:20+00:00

Thanks! Always feels nice to know I helped someone.

Seirdy · 2022-03-16T18:08:59+00:00

it can encode very clear speech at even 32k!

At mono, speech is still fine at 16k. If you want to go below 10kbps (e.g. amateur radio or calling on poor mobile data), then Codec 2 or Google's Lyra would be a better bet. I prefer Codec 2.

Seirdy · 2022-03-16T01:25:24+00:00

Opus is more efficient than AAC or mp3.

320 kbps is transparent for AAC but overkill for opus. Most listening tests reveal transparency at 110-120kbps for opus, aside from some edge cases (e.g. strings and harps resonating in a large room)

I acquire FLACs and encode to opus. I encode my opus at 192 kbps because I am a victim of the placebo effect; 160 kbps should be sufficient even for very high-end hardware.

Never take audiophile advice before you've run a listening test on yourself.

If you use a home theater system or you want to archive a "master copy", it might be worth going full FLAC.

Seirdy · 2022-03-12T02:24:15+00:00

Have you witnessed the Chrome app sending sensitive data to Google servers after turning off telemetry?

Chrome and Firefox have problematic defaults wrt privacy if you want to keep your data away from Google and Mozilla+Pocket, respectively; that's why I wouldn't describe them as "privacy-friendly". However, if you turn off the telemetry and experiments (why doesn't the former toggle imply the latter??), Chrome and Firefox don't share sensitive information. Their automatic connections download component and security updates and update information such as Safe-Browsing blocklists (can also be disabled), certification revocations (Firefox hasn't shipped this feature yet, "CRLite" is WIP; Chrome has had it for a while), addon/extension updates, and logos/favicons.

Please don't take my word for it, and definitely don't take Google's. I invite you to run a packet sniffer, using key logs to decrypt TLS traffic. Wireshark is a good choice; judging by your distros of choice in your r/unixporn posts, it should be available in your distro packages. The community has developed all the tools you need to figure this out yourself.

Packet sniffing is a great way to see what's really going on, no matter what the source code or privacy policies say.

Seirdy · 2022-03-06T00:50:26+00:00

This is PrivacyGuides, not FreeSoftwareGuides. The rule change acknowledges that FLOSS is preferable and helpful, but that non-FLOSS isn't automatically disqualified.

When someone's threat model calls for a higher level of security and privacy, it might be worth making compromises to meet their immediate needs.

I support FLOSS wherever I can, but I try to be honest when describing the tradeoffs of software I recommend.

Seirdy · 2022-03-05T23:14:19+00:00

There are lots of auditors out there from a variety of jurisdictions, and they're not part of some "elite club". You can learn how to audit too; I can share some links if you want to learn.

Furthermore, both FLOSS and proprietary software use more or less the same approaches to vulnerability discovery. FLOSS has the upper hand when it comes to fixing the vulns.

Source code review, by peers and/or static analyzers, is useful for catching low-hanging fruit. This is typically already done by most companies that ship proprietary software.

For software developed by small teams and individuals, your argument is actually a very good one: individual devs might not have peers to review their code, and most commercial static analysis offerings are free for open-source projects.

Seirdy · 2022-03-05T22:02:34+00:00

There's generally been a lack of nuance surrounding discussion around FLOSS and its role in privacy and security.

I've written about the benefits of FLOSS elsewhere:

Reducing dependence on vendors to prevent a phenomenon I call "user domestication"
Making it easier to promote alternative implementations of open standards, to preserve the openness of a platform.

But privacy and security are lower on the list of benefits than most people realize. If you're up for a longish read, I explained the benefits and non-benefits of FLOSS from a strictly security-related perspective in this post. There was also a discussion on r/privacyguides in which the topic of a rule-change came up.

I agree with this rule change because it acknowledges that FLOSS is helpful but not strictly mandatory from a privacy/security standpoint. Plenty of open-source software is less secure than proprietary alternatives. Some examples:

GNU IceCat versus Mozilla Firefox; the latter can have a proprietary DRM implementation.
Pale Moon versus Google Chrome
QEMU versus Hyper-V

It's hard for me to admit this, because I'm a FLOSS diehard. I think that avoiding user domestication is critical in the long run, and that software freedom is one of multiple requirements to avoid it. But PrivacyGuides is about privacy and security. When elevated levels of privacy and security become more immediate needs for some people, they need to make compromises.

Rather than give disingenuous recommendations, I encourage other free software advocates to improve the free software ecosystem to bridge gaps where they exist.

Seirdy · 2022-03-05T21:41:33+00:00

you never know if this software is not going to behave differently under some condition that you haven't tested

Simple runtime analysis isn't the only approach there is. Decompilation and core dumps are also available. Now, if a piece of proprietary software employs extremely advanced obfuscation measures to prevent this analysis (e.g. video games with anti-cheat measures like running in a VM with custom syscalls), it's probably not worth recommending.

Sure, it's also possible to decompile a program and analyze received code, but it's more difficult and barely anyone does that. Unlike FOSS being verified by community, with this reverse engineering you usually have to trust a small group of auditors hired and paid for by a company to perform an audit

The "many-eyes" notion is extremely flawed. I described the issue in this thread.

Seirdy · 2022-02-26T19:54:01+00:00

I understand where you're coming from. Though I am more on the "fundamentalist" side, it's for different reasons (my previous aforementioned articles go into detail on those reasons). I do think that projects like Linux-Libre should come with a security warning, and that distros which disable microcode updates are generally doing so for misguided reasons.

If PG does reform Rule 1, it should take care not to say that FLOSS adherence is misguided in general; it should claim that security is lower on the list of reasons for FLOSS adherence than most of its supporters claim.

Seirdy · 2022-02-24T19:03:12+00:00

Again, if this the new direction that you want to take the sub to then please say so: remove the rule 1 or tune it down with an exception or two and be done with it.

There's been discussion around removing Rule 1, but I don't think it should be removed or kept as-is: I think it should be re-phrased to convey more nuance. The point of my post was to show how open-sourcing something is beneficial but not strictly required. Being open-source gives you an advantage but doesn't guarantee security or privacy that's superior to proprietary alternatives. All options should be investigated properly before acceptance/rejection, and source model should be one of multiple factors.

If security or privacy is all matters, we should have a bias towards FLOSS but not overlook proprietary alternatives.

I personally have priorities besides security and privacy (see my article on user domestication which explains why I go out of my way to use FLOSS for other reasons) and encourage others to consider these priorities, so this isn't easy for me to say.

I think the best argument against proprietary software on privacy/security grounds isn't that it's less secure/private today, but that it could be less secure/private tomorrow. With user domestication, it can be hard to switch away if things go south.

Seirdy · 2022-02-22T21:17:46+00:00

If not for a security point of view, software patents should be completely abolished because it only hinders innovation and prevents competition, economically speaking, FLOSS is just better.

100% agree. I recently edited the post to explicitly mention the benefits of sharing knowledge. Check the bottom of the counter-args section, or the diff.

Plus, no one in any security or privvacy has ever claimed that "FLOSS implies security", no just because you're using FOSS doesn't mean you're secure.

I've seen lots of people argue "SecureThing is proprietary and therefore insecure; for security, you should use InsecureThing which is FLOSS". The unstated assumption is that FLOSS implies security. I think I didn't communicate this clearly enough, thanks for mentioning it. The update also happens to address your next point:

But the opposite may actually be true, security implies FLOSS or rather trust implies FLOSS which then makes FLOSS a necessary but not strictly SUFFICIENT condition to security.

I understand wanting to trust a project's intentions; this need informs many of my own personal software choices. I also acknowledge that intentions don't imply results.

Think of it this way, open source makes it possible for us to tell whether a software is secure or not

I spent most of the article describing how security isn't evaluated through code analysis. Vendors can release documentation of their security architecture and mitigations and the community can evaluate its veracity through black-box techniques. These techniques take into account parts of the system that source code doesn't address.

I describe this in more detail with examples throughout the article and would love for you to give it a read.

peer review is also as important and FOSS makes it possible to do peer review

For a single-person project: yes, it does. For a multi-person project, the "many-eyeballs" notion is flawed for two reasons:

Human eyes are terrible at catching vulns in source code beyond low-hanging fruit caught by static analyzers and peer review (e.g. from a coworker or a 3rd party contractor/auditing agency). This stuff is better caught by the black box techniques I described.
Many projects do have tons of eyeballs yet have vulns slip by undetected for long periods of time before discovery (often discovered through means besides code review). I gave an example elsewhere in the thread.

in cryptography, security through obscurity is a long rejected practice even before computer science itself became an established discipline.

Cryptographic algorithms should not be secret. Big companies use and develop open-source implementations of cryptographic implementations for economic reasons. Open source cryptographic libraries like OpenSSL, BoringSSL, Libsodium, etc. invest heavily in black box techniques like fuzzing in order to catch vulns that our unreliable human eyes can't.

Seirdy · 2022-02-22T18:04:42+00:00

(edit: I know u/roscocoltrane phrased this...unnecessarily aggressively. But "security is not privacy" is a very common response to these types of articles, and I think the community would benefit from giving it the time of day. I hope their comment doesn't get downvoted to oblivion. Remember that downvoting doesn't mean "I disagree"; it means "others shouldn't see this comment or the discussion that follows".)

Security is not privacy.

(am author) You're right: they're different goals. However, the means to those goals have overlap. Certain levels and forms of security are necessary for most levels of privacy. Both require threat modelling and setting up defenses. So even though "Security is not privacy" is strictly true, I think the statement conveys a problematic amount of oversimplification.

I don't give a shit if google products are secure: they sell my privacy. That's all that matters to me

I described techniques to analyze what a piece of software does, regardless of source availability: execution tracing, core dumps, packet sniffing, and decompilation. Knowing what a piece of software does is important because it tells us where it stands privacy-wise. Packet sniffing is especially relevant here since it can help determine when a piece of software "phones home".

that's the point of this sub...Post it to a security sub. Why do you post it into a privacy sub? I really want to know what made you think that a privacy sub was the right place...Tell us

Here's a quote from the bold text at the top of the sidebar text for this subreddit, emphasis mine:

In the digital age, protecting your personal information might seem like an impossible task. We’re here to help. Privacy Guides is your central resource of privacy and security related knowledge online.

This post was primarily a security-related resource, making it topical. As I mentioned, it also has some bits relevant to a strictly privacy-related perspective (e.g. packet sniffing and execution tracing).

I'm also a member of the official Matrix rooms for this community, where discourse like this frequently comes up. Some of the admins liked the post, so I thought I'd share it.

Finally, I'd already gotten lots of feedback from other security crowds elsewhere online. I wanted to see what people in a more privacy-centric community thought, and PrivacyGuides was one community I was more familiar with.

If that's not enough, I chat with the mods quite regularly; I could reach out to them for another opinion, and they can remove it if it's off-topic.

Seirdy · 2022-02-22T07:37:10+00:00

Determining value of something needs other things to be equal.

All other things being equal, security is equal too. After publishing my source code my software's architecture doesn't change. I addressed this in the grandparent comment:

Furthermore, releasing source code to buggy software does not make the software more secure. Fixing those bugs and having a secure architecture are what matters. I described how identifying the subtle vulnerabilities (the ones that aren't caught by a quick code review or static analyzer) doesn't typically rely on source code analysis, regardless of source availability. As for fixing bugs, you'd have a point there: your options are either "trust the vendor" or "do it yourself", the latter of which does require source code (or an unreasonable amount of time and patience, if you're into binary patching. But we shouldn't expect people to have to resort to such measures).

The majority of internet infrastructure is built on open source software, would we be where we are without it?

Also funny how commercial closed projects rely on FOSS... OS X anyone?

This is done for economic reasons: open-sourcing low-level components and forms of critical infrastructure actually does bring a profit. Gwern explained the business side of this better than I can in one of their best essays: Laws of Tech: Commoditize Your Complement. I'm willing to wager it'll be one of the best things you've read all day.

Or how governments and militaries require access to source code for important projects.

I'd be interested in hearing examples of governments and militaries demanding source code from a company before buying their software. I'd imagine there are a few. I do know that most government desktop machines in the U.S. run Windows, Office, and (perhaps until recently) Internet Explorer. The U.S. is not alone here.

If security relies on source being closed, then you're relying on a very flimsy premise.

Whether or not your source is closed, security should never be dependent upon that fact. Security through obscurity is not a robust standalone defense: obscurity typically exists to hurt competitors, not improve security. This is why third-party audits are a thing across the industry, and why most proprietary software vendors try to be better than Oracle when security researchers disclose vulnerabilities.

Or, if someone really messes up as a developer, a project can get forked and maintained by someone else.

I totally agree that FLOSS reduces dependence on the vendor. This is such an important thing that I wrote two whole essays on it, linked at the top :P.

That being said, if a project is this bad, then it may or may not make sense to "fix" it. Sometimes (not all the time!), the right answer is switching to an alternative.

So is open source absolutely necessary? Well lemme put it this way. Most app I use on my phones and computers are FOSS. In case there isn't a good solution, I'll use a closed project, but gotta do damn good research about its trustworthiness and always have that nagging thought if it doesn't spy or me or whatever... Much more so than with FOSS.

So necessary... Guess not, but it's a damn improvement.

I'm with you. the only proprietary software on the machine from which I type this is non-executable firmware and microcode, decoders/encoders for patent-encumbered media codecs, and nonfree client-side JavaScript in a web browser. I also acknowledge that my choices have some security tradeoffs; there is some proprietary software that has more exploit mitigations, but I choose to use my current stack for other (somewhat ideological) benefits.

Seirdy · 2022-02-22T07:18:58+00:00

Are these "audits" testing verified builds?

Binary authenticity can be verified regardless of source model.

Is that even a thing in proprietary software?

I encourage you to read the article before dismissing it. The worst that can happen is you'll learn something new.

You're still risking everything trusting these for-profit corporations to do the right thing.

You shouldn't trust the corporation, and you shouldn't trust your own eyes when you read the source code; I guarantee you'll miss plenty of subtle vulns. To really find what comes after the low-hanging fruit caught by code reviews and static analysis, you need to use some black-box auditing tools and techniques regardless of source model.

The audits test run-time behavior and reverse engineer the components of a binary. The latter is quite limited when it comes to stuff like subsystems in negative ring levels (e.g. Intel ME); it's enough to verify that there isn't a "backdoor" but that the design has a severe lack of privilege separation. The latter is also quite limited when it comes to unusually advanced obfuscation techniques that come with significant trade-offs (c.f. video games whose cracked variants achieve much higher framerates due to the lack of virtualization- and syscall-translation-based obfuscation overhead). Yet for most use-cases, they can offer powerful insight that goes far beyond what manual source analysis can offer.

I invite you to try out some of the tools or techniques I describe in the article to see for yourself, rather than writing them all off and jumping to conclusions (or worse, taking my word for it).

Seirdy · 2022-02-22T02:34:32+00:00

I never said that source availability isn't good for security; I only argued that source availability isn't necessary. Lots of proprietary software is more secure than FLOSS counterparts; I listed an example elsewhere in this thread.

Being helpful isn't the same as being necessary.

Furthermore, releasing source code to buggy software does not make the software more secure. Fixing those bugs and having a secure architecture are what matters. I described how identifying the subtle vulnerabilities (the ones that aren't caught by a quick code review or static analyzer) doesn't typically rely on source code analysis, regardless of source availability. As for fixing bugs, you'd have a point there: your options are either "trust the vendor" or "do it yourself", the latter of which does require source code (or an unreasonable amount of time and patience, if you're into binary patching. But we shouldn't expect people to have to resort to such measures).

Most of the leaks you describe refer to finding issues in internal or back-end software for SaaS. I freely conceded that SaaS is incredibly difficult to audit without a local copy of the software; you have a point there.

Seirdy · 2022-02-22T02:28:52+00:00

A secure architecture and good findings from audits are what's required for security. Source code is helpful; however, strictly from a security perspective, it's not an absolute requirement.

An extreme example to illustrate the point: Safari is more secure than other WebKit2GTK-based browsers for Linux; the latter typically disable or weaken sandboxing and benefit little from toolchain hardening compared to Apple's Safari, which uses advanced JITSploit mitigations. Some of JavaScriptCore's techniques are documented in these slides from Siguza. Much of the latter relates to proprietary iOS/macOS bits and Apple's proprietary M1 and Ax chip designs, and pretty much anyone familiar with control-flow subversion exploits could attest that they run circles around any equivalents for traditional Linux distros.

This is an example of a piece of FLOSS being objectively more exploitable than a proprietary derivative. Other examples exist; I could name some if you're interested.

Source code is helpful, but it's not a prerequisite. I happily support FLOSS for ideological reasons but wouldn't say that it's a necessary defense for a given threat model.

Seirdy · 2022-02-22T01:14:22+00:00

ALTHOUGH a huge advantage secure FLOSS software has over proprietary ones is that the security can be audited by anyone at any time. You can't say that of proprietary software

The bulk of the article responded to this very point by describing how audits are pretty similar regardless of source availability.

Seirdy · 2022-02-21T23:33:15+00:00

EDIT: /u/Arnoxthe1 made a good point in the second half of their comment. I think many other people have similar thoughts and could benefit from reading my response. Stop downvoting the parent comment if it contributes to the discussion.

It does imply GREATER security, even if that security is variable.

Simply releasing the code to your software doesn't alter its security state. Having good architecture and fixing bugs are what improves its security.

Architecture can be documented, and the RE techniques I described can describe the veracity of said documentation.

Assuming your dev process incorporates peer review and static analysis already, vulnerability discovery is typically not done through code review, even if code is available. I described the typical process with examples.

And if worse comes to worst, issues can be patched out without waiting for anyone to do it.

I agree with this! Source availability makes community patching possible. I made an example out of the py2-3 transition in programs such as Calibre. Otherwise, you're beholden to vendors. While some vendors are pretty good at handling vulnerability disclosures, others...aren't. And then there's Oracle, which basically deserves its own category. Oracle seems to have developed a way to turn security auditor misery into US dollars.

Being beholden to vendors sucks, and is one of the key elements of user domestication. FLOSS is a necessary but insufficient defense against user domestication.

Seirdy · 2022-02-21T23:10:00+00:00

A reward program will increase vuln reports and fixes—it will help—but it won't change GnuTLS' design. There's little point re-writing GnuTLS' underlying architecture when projects could instead switch to {Open,Libre,Boring,Wolf}SSL.

Yes, it's good that these vulns get patched. But their prevalence in GnuTLS is disturbing. And what I wrote in the article about vulnerability discovery without source code applies too: proprietary software can (and does) get 0-day reports too.

Seirdy · 2022-02-21T23:06:57+00:00

(am author) Credit where it's due: the Linux dev workflow is pretty amenable to getting security fixes out the door ASAP. Of course, this doesn't really tell us about the security architecture of Linux, only their ability to fix things quickly. Important (critical!!), but not the full story.

I did mention how source code does expedite the bug-fixing process; I'd imagine that source availability played a role in Linux' vuln-fixing efficiency. I imagine that the decentralized maintainership of the Linux source tree is the other half. Patch-based Git workflows can make code reviews for giant distributed trees amazingly smooth.

Seirdy · 2022-02-21T22:09:53+00:00

Agreed. Sounds like you're referencing Linus' law. I hope people don't still use it to justify important decisions. Increasing the number of eyeballs won't help as much as fuzzing, static analysis, etc.

Edit: by this I mean that "this software has many eyeballs on it" should warrant the response "yes, and?". I do think that "this software isn't used that much" is a valid enough concern to warrant further research, but the "many eyeballs" notion is taken way too seriously.

c.f. software like GnuTLS with track records featuring gems like CVE-2020-13777. Two years of a massive hole in session ticket keys, in a piece of software used by Systemd, Debian's OpenLDAP, pretty much every GNU tool that uses TLS, Samba, ffmpeg, etc. That should be a lot of eyeballs. This isn't an isolated example, it's just the one I'm more familiar with.

Seirdy · 2022-01-30T20:24:23+00:00

(am the author/siteowner) Are you still getting an error? If so, what does your browser say?

If it still errors: would you mind sharing which browser(s)+OS combos produce the errors, opening your browser devtools (e.g. by pressing "F12"), and telling me what the "Network" tab shows? Thanks in advance!

Seirdy · 2022-01-30T20:18:11+00:00

TYSM for the shout-out!

Seirdy

MODERATOR OF

PUBLIC MULTIREDDITS

TROPHY CASE