In 2018 I announced the creation of my "Skip Mobile Wikipedia" Firefox add-on, which automatically
redirects you to the desktop version of the site. At the time it worked on both standard desktop Firefox and in Firefox for Android, life was great.
Unfortunately at some point, Firefox stopped allowing arbitrary add-ons on Android and it was disabled. It was still usable in the "Nightly" edition, but that wasn't very user friendly.
Anyways, fast-forward to earlier this month, Firefox has re-enabled general add-on support, so
"Skip Mobile Wikipedia" is installable and works again on Android. The source code is the same, I haven't had any need to update it since 2020.
I personally use the responsive Timeless skin, which I think provides a nicer viewing and editing experience from my phone. Happy browsing!
I am privileged to work for a non-profit organization, the Freedom of the Press Foundation, which allows me to work full-time on free and open-source software, namely SecureDrop. It also pays the bills and lets me spend me free time doing other stuff that's good for humanity, like contributing to wikis, running a Mastodon server and riding bikes.
FPF accomplished a lot of important things this year, but like every other non-profit, we're currently doing our end of the year fundraising drive, hence this blog post.
If you like my work, whether on SecureDrop or just in general, and have the means to do so, I'd appreciate you donating to FPF: https://freedom.press/donate/ (if you live in the US, this donation is tax deductible). Click the checkbox that says "This donation is in tribute of someone", and then say the gift is in honor of me, "Kunal". (You're also welcome to type other stuff, like "legos" or "boba tea".)
Hate my work? That's fine too, just pick the option that says "This gift is in opposition to" and mention my name. You could also type other stuff here, like "the Kragle" or "boba tea haters".
Now that you've read this far, I'll also mention that we have a merch store with FPF and SecureDrop swag, including stickers! If you use the coupon code "FPF2023" you'll get a 15% discount (only on Nov. 27 aka Cyber Monday).
Thanks.
I haven't been very good with writing about what I've been working on in SecureDrop-land, but here is: Migrating SecureDrop’s PGP backend from GnuPG to Sequoia
over on the SecureDrop website. You should read it, and then come back to read the rest of this.
We had been discussing Sequoia internally for a while, but I officially filed an issue titled "Use Sequoia-PGP instead of gpg/pretty_bad_protocol" in April 2022. I pushed
a first WIP of the Rust code to a branch named oxidize on July 8, 2022 and had it working in the development environment by the 14th. TBH that was the easy part, migrating existing sources from GPG to Sequoia was going to be
the hard part.
Small tangent, I was very fortunate to grow up around a lot of Sequoia trees, and I have very fond memories of visiting Muir Woods National Monument as a kid. So when I had
to pick a name for the Rust crate, I tried to stay with the theme, and went to the Wikipedia disambiguation page for Sequoia, clicked on the first link, Sequoioideae,
read "...commonly referred to as redwoods", and then immediately ran cargo new redwood --lib. I anticipated we'd switch to a generic, boring, name like rust but that didn't end up happening :-).
Exporting public keys is pretty easy, but GPG stores secret keys in its own custom s-expression thing (documented as "...easier to read and edit by human beings", okay.), which we would have to write something
custom to read. I flailed around trying to do so but never really got anywhere. Sequoia opened a ticket on their end for supporting GPG's format, but as of this writing, it hasn't seen any real progress (which is fine and understandable!).
Also I got busy with other SecureDrop things (e.g. "Reorganize Debian packaging, have debhelper do most of the work", which deserves its own blog post).
At the end of December 2022, Sequoia announced their chameleon project to replace the gpg CLI. In January 2023 (this year!) I discussed whether using that was an
option in the Sequoia IRC channel, and Neal (who is fantastic), suggested just using GPG directly. Great idea!
Now that we had a real migration plan, February and March had some internal discussions on whether to move forward with this, and I started working on it for real in May. The first PR
was up by the end of May and landed the first week of June.
The second major PR was posted mid-July and merged at the beginning of October! There were a number of smaller
PRs in the middle, but that was "step 2" in my high-level roadmap.
There was a lot of good back and forth during review from SecureDrop team members, Sequoia developers and other volunteer contributors. And related PRs from other SecureDrop team members.
Everything else landed in October, and then this week I finished running some benchmarking, which, surprise surprise, showed that calling the Sequoia Rust code was faster than
shelling out to GPG.
SecureDrop 2.7.0 powered by Sequoia should be (knocks on wood) released in a few days, which will be the largest milestone to date of this multi-year project. And as the blog post pointed out, there's still a lot of work to do.
This is the first Rust project that I've worked on that is being shipped to production users (all the wiki bots I've written really don't count), and it's been a blast. It certainly won't be the last ;-)
I tend to spend a lot of time reading. When I was a kid it was as many books I could carry home from the library; later it would become newspapers, blogs and online things.
I never bothered to track what I was reading, because there was so much of it and re-reading something you enjoyed isn't that bad. It also felt invasive (in a privacy sense), but that was mostly because everyone was using the
Amazon-owned Goodreads. For a while I used the perfectly named "Badreads" app, but I never felt comfortable with it.
Anyways, this is all to say that I now have an account on bookrastinating.com (also perfectly named!!), which runs the ActivityPub-enabled BookWyrm software.
You can follow me as: @legoktm@bookrastinating.com.
I've been posting everything as followers-only, and I'm planning to only approve people I know well (my current vague criteria is that we've met in real life).
The actual federation from Mastodon is pretty meh, you can see when I add books to my "to read"
list and when I start and finish books, but can't read the actual reviews I've been writing. I'm curious to see if it's better for people who are federating from other BookWyrm instances.
If I end up writing something brilliant that I want public I'll probably publish it on my blog.
In any case, I'm fine with those limitations for now, this is largely an exercise in tracking what I read rather than trying to be uh, social about what I read. I appreciate that BookWyrm seems to have some actual privacy controls in place instead
of Mastodon's "everything is public".
Last week The New Republic published an article by Melissa Gira Grant titled, "The Mysterious Case of the Fake Gay Marriage Website, the Real Straight Man, and the Supreme Court" about how the request for a gay wedding website underpinning the 303 Creative LLC v. Elenis case was supposedly fake.
TNR followed it up with "The Supreme Court Doesn’t Care That the Gay Wedding Website Case Is Based on Fiction", which really
gets to the heart of the matter in the opening line: "If the Supreme Court persists in making rulings based on fiction, how can we take any ruling seriously?"
But this is far from a new issue. We can look at the landmark 2003 Lawrence v. Texas decision for another example of a ruling based on incredibly questionable "facts". In that case, Lawrence, Garner and Eubanks (all gay),
were at Lawrence's apartment. Eubanks, who had supposedly been drinking, became jealous that Lawrence and Garner were flirting. Eubanks left the apartment to go to a vending machine and called the police, falsely reporting
that there was a black man with a gun at Lawrence's apartment.
Four officers respond, one claimed they saw Lawrence and Garner having anal sex, another said they were having oral sex and the other two didn't make any mention of it in their reports.
They were arrested and charged with having "deviate sex", specifically anal sex. They would eventually be represented by Lambda Legal and win in a 6-3 United States Supreme Court ruling
that struck down all remaining sodomy laws and reaffirmed the unenumerated right to privacy.
Except...the facts of this case were also a lie. Lawrence and Garner weren't having sex, they weren't even in the same room when the police entered!
This would be first revealed in the 2012 book Flagrant Conduct: The Story of Lawrence v. Texas by law professor Dale Carpenter.
Dahlia Lithwick wrote a good summary of the book for The New Yorker, explaining that Lambda Legal needed to find actual plaintiffs who had been charged under a sodomy law
to challenge their constitutionality. But being convicted of such a charge had significant consequences, so attorneys wanted clients with "with little to lose". Enter Lawrence and Garner.
Here's how Lithwick described it:
The legal opportunity depended, however, upon persuading the defendants to go along with an unusual strategy. High-powered lawyers would represent Lawrence and Garner, as long as they agreed to stop saying they weren’t guilty and instead entered a “no contest” plea. By doing so, the two were promised relative personal privacy, and given a chance to become a part of gay-civil-rights history. The cause was greater than the facts themselves. Lawrence and Garner understood that they were being asked to keep the dirty secret that there was no dirty secret.
That’s the punch line: the case that affirmed the right of gay couples to have consensual sex in private spaces seems to have involved two men who were neither a couple nor having sex. In order to appeal to the conservative Justices on the high court, the story of a booze-soaked quarrel was repackaged as a love story. Nobody had to know that the gay-rights case of the century was actually about three or four men getting drunk in front of a television in a Harris County apartment decorated with bad James Dean erotica.
They pled no contest to the charges and largely stayed out of the limelight while their attorneys took the lead and won a landmark victory. (Lithwick has a parenthetical stating, "Carpenter is careful throughout to show that
none of the civil-rights lawyers lied or misrepresented the facts.")
You could presumably write a similar article titled, "The Supreme Court Doesn't Care That the Anal Sex Case Is Based on Fiction" (consider this to be the alternative title for this blog post). It is entirely believable that a cop in
Texas in 1998 would falsely accuse two gay men of having sex so they could be arrested for something after responding to a false report.
It's not hard to find other cases where the Court relied on faulty facts, take a look at the dissent in last year's Kennedy v. Bremerton School District
for example.
It's certainly worth asking whether this even matters. Dareh Gregorian wrote a piece for NBC News this week titled, "'Sham' website customer likely didn't affect Supreme Court ruling on same-sex weddings, experts say".
Good to know, but this doesn't address the opening question: "If the Supreme Court persists in making rulings based on fiction, how can we take any ruling seriously?"
To put it another way, in Lithwick's New Yorker piece, she pointed out, "Since the days of Brown v. Board of Education, and right up to District of Columbia v. Heller, the 2008 handgun-ban case, major test cases, [attorneys] knew, have turned as much on selecting the perfect plaintiffs as on the law being challenged."
And if you can't find them, just make them up.
I had a wonderful time at the 2023 Wikimedia Hackthon in Athens, Greece, earlier this month. The best part was easily seeing old friends that I haven't met in person since
probably 2018 and getting to hack and chat together. I also met a ton of new friends for the first time, even though we've been working together for multiple years at this point! I very much enjoy the remote, distributed nature
of working in Wikimedia Tech, but it's also really nice to meet people in person.
This post is very scattered because that was my experience at the hackathon itself, just constantly running around, bumping into people.
I wrote that I wanted to work on: "mwbot-rs and Rust things, technical governance (open to nerd sniping)". I definitely did my fair share of Rust evangelism and had good discussions regarding technical governance (more on that another
time). And some Mastodon evangelism and a bunch of sticker trading.
But before I got into hacking things, I tabulated and published the results of the 2022 Commons Picture of the Year contest, which I think turned out
pretty well this year. Of course, the list of things to improve for next year keeps getting longer and longer (again, more on that in a future post).
At some point during conversation, I/we realized that the GWToolset extension was still deployed on Wikimedia Commons despite being, well, basically dead. It hadn't been used in over a year and last rites were administered back in November (literally, you have to look at the photos).
With a thumbs-up from extension-undeploying expert Zabe (and others), I undeployed it! There was a "fun" moment when the venue WiFi dropped so the scap output
froze on my terminal, but I knew it sucessfully went through a few minutes later because of the IRC notification, phew. Anyways, RIP, end of an era.
And then Taavi deployed the RealMe extension, which allows wiki users to verify their Mastodon accounts and vice versa. But we went for dinner immediately after so Taavi wasn't even the
first one to announce it, Raymond beat him to it! :-)
I spent a while rebasing a patch to bring EventStreams output to parity with the IRC feed that was first posted in April 2020 and got it merged (you're welcome Faidon ;)).
One of the last things I did before leaving was an interview about MediaWiki in the context of spinning up a new MediaWiki platform team (guess which one I am). At one point the
question was "What is the single biggest pain point of working in MediaWiki?" Me: "can I have two?"
Reviewed a bunch of stuff:
Probably the most important patch I wrote at the hackathon was to add MaxSem, Amir (Ladsgroup), TheDJ and Petr Pchelko to the primary MediaWiki authors list on
Special:Version. <3
Despite having a bunch of wonderful people being there, it was also very apparent who wasn't there. We need more regional hackathons and after a bit of reassurance from Siebrand and Maarten, it became clear that we have enough
Wikimedia Tech folks in New York City already, so uh, stay tuned for details about some future NYC-based hackathon and let me know if you're interested in helping!
Final thanks to the Wikimedia Foundation for giving me a scholarship to attend. I really can't wait until the next time I get to see everyone again.
