Read WordPress 5.2: Mitigating Supply-Chain Attacks Against 33% of the Internet by Scott Arciszewski

WordPress 3.7 was released on October 24, 2013 and introduced an automatic update mechanism to ensure security fixes would be automatically deployed on all WordPress sites, in an effort to prevent recently-patched vulnerabilities from being massively exploited in the wild. This is widely regarded by security experts as a good idea.
However, the WordPress automatic update feature had one glaring Achilles’ heel: If a criminal or nation state were to hack into the WordPress update server, they could trigger a fake automatic update to infect WordPress sites with malware.
This isn’t just a theoretical concern, it could have happened if not for WordFence’s security researchers finding and disclosing an easy attack vector into their infrastructure.
WordPress 5.2 was released on May 7, 2019 and provides the first real layer of defense against a compromised update infrastructures: offline digital signatures.

Everybody is swooning over Google’s upcoming automated captions, except zero of the people who actually need them. I have to wondere how it is that as an industry we manage to convince ourselves that we’ve collaborated with people with disabilities on all this amazing new accessibility tech that helps us avoid the obvious solution: Do it right in the first place. I’m sure there were messages across email lists, or surveys, or whatever, with asks for testers, ETC. But the deaf community has been saying for years that automated captions aren’t an optimal solution, and it seems arrogant to me at worst and well-meaningly naive at best that all that advice about automated captions would be ignored for the sake of Google’s business goals. We know what accessibility advancements look like, because people with disabilities have been telling us what they need, for years. Maybe one day as an industry we’ll actually start listening. I’m not holding my breath for the foreseeable future though.
Read Who Do You Sue? State and Platform Hybrid Power Over Online Speech by DAPHNE KELLER

This essay closely examines the effect on free-expression rights when platforms such as Facebook or YouTube silence their users’ speech. The first part describes the often messy blend of government and private power behind many content removals, and discusses how the combination undermines users’ rights to challenge state action. The second part explores the legal minefield for users—or potentially, legislators—claiming a right to speak on major platforms. The essay contends that questions of state and private power are deeply intertwined. To understand and protect internet users’ rights, we must understand and engage with both.

This essay from the Hoover Institute is worth a read for anyone discussing either online speech in general or the embarrassingly wrong pieces on Sec. 230 which have appeared in both Vox and the Washington Post in the last few days. Click here to read the full version in as accessible a format as possible without having to download the document yourself and tag it.
Read ‘Work with Facebook or die’: Mark Zuckerberg by DARREN DAVIDSON

A senior Facebook executive has privately admitted Mark Zuckerberg “doesn’t care” about publishers and warned that if they did not work with the social media giant, “I’ll be holding your hands with your dying business like in a ­hospice”.
In extraordinary comments, Campbell Brown, Facebook’s global head of news partnerships, indicated to publishers and broad­casters in a four-hour meeting last week that despite Mr Zuckerberg’s view, she would help publishers build sustainable business models through Facebook.

This doesn’t just apply to news organizations. Anyone who publishes to Facebook is deemed a publisher by them. And anyone who has worked in the accessibility space for two seconds knows that if you don’t have stakeholder buy-in, efforts to remedy a situation like this are doomed to fail. So don’t hold your breath on Facebook’s global head of news partnerships being able to hault Zuck’s advancements toward publishing dominance.
Read Gab is forking Brave, and Brave is forking furious by Guillermo Jimenez

Gab is creating its own web browser using Brave’s open-source code, scrapping the BAT token, and replacing it with Bitcoin Lightning Network integration.

Torba says he doesn’t understand the controversy: “The entire point of open source is to allow others to build upon an existing codebase and add more value,” he says, adding that Brave itself “is a fork of the Google Chromium project,” from which it benefited greatly.
“Open-source projects are forked all the time, GitHub even shows the fork count on every repo and the community uses it as a badge of honor. I can’t imagine any legitimate reason why Brendan or anyone else would have a problem with this.”

He forgot the part about how nazism doesn’t add value.

Read It’s Time to Retire “RTFM” by April Wensel

The culture of programmers and other technologists is plagued by toxic elitism. One of the manifestations of this elitism is an unrelenting hostility toward so-called “non-technical” people (a distinction that’s also ready for retirement), beginners, and ultimately anyone asking for help. If you’re unconvinced, please spend a few minutes browsing the popular¹ question-and-answer site, Stack Overflow² (just make sure you prepare yourself emotionally beforehand).

I completely agree with the author of this post that there is definitely a lot of hostility toward beginners in the tech community. However, there are absolutely times when RTFM is not only appropriate, but necessary. Take, for example, developers and accessibility, specifically semantic markup. At a certain point, developers should be taking on the responsibility of learning how to write code that runs in browsers which adheres to web standards. Another example: It’s not the job of accessibility practitioners to fix the resultant problems when standards-compliant code isn’t deployed, and it’s not our job to whip up complex yet accessible components to submit as pull requests for every open source project on the internet. At some point, developeres need to learn to do their jobs, and sometimes RTFM is the only way to get that point across. You literally cannot make things accessible without being able to consult documentation on the subject, especially when you’re starting out. You must learn how to research so you can get to a point where you can ask the appropriate questions and then work on implementing a solution. RTFM or similar isn’t appropriate when someone indicates they’ve tried to find the answer on their own and they are stuck. It’s not appropriate on the first day of class. But to say that we should throw it out completely ignores the reality that for things like accessibility or learning a programming language, reading the documentation is a necessary component of that process. It ignores the reality that, in cases where people with disabilities are asked to do the heavy lifting, (accessibility work, for example), there’s a very likely possibility that people with disabilities, who already have to deal with the consequences of developers and designers breaking things, are then tasked with ensuring that they are fixed, by spoonfeeding if necessary, and very often, for free. That is very tiring work, and there comes a point where asking people with disabilities to be compassionate to designers and developers becomes an effort that does not produce results, wastes time and energy, and creates situations where all that work will have to be done, again.