Today is Pachamama Raymi, the Quechua culture’s Mother Earth Feast.
I call it out, because it’s an interesting holiday on a day with some of the most generic-sounding holidays that I’ve seen, including what might be my favorites.
Nothing says friends, family, and community, like not bothering to insert any informative nouns into your holiday’s name. At that point, it’s also the unbirthday of billions of people, I would imagine.
Not that I don’t love the idea of an utterly generic holiday to celebrate—I thought about throwing together a drab symbol and color scheme to go with Generic Holiday—but we have code to get to.
As mentioned last week, work on the blog started out with the citation plugin that I created to replace the hack of using a heading. I also realized, at some point, that I never published the CSS for the new pull quotes that started me down the path of learning about plugins, so that’s available now, as well.
The other bad news is that Firefox’s “Facebook Container” add-on (generally a good thing that I rely on) now incorrectly flags all e-mail fields as leaking information to Facebook. Digging deeper, it looks like I’m not the only person baffled by this behavior; it’s apparently to sell “Mozilla Relay”—an e-mail alias service—and I was able to make the spurious detection go away by adding
mzp-js-email-field to the CSS classes—I found the class name by going to
Venting That You Can Skip
As someone who hates working with Chrome and can just barely tolerate Chromium, I’m not thrilled to find Mozilla making toxic decisions like this. They’re basically using security consciousness to spread paranoia across the Internet to collect e-mail addresses for some unknown purpose. That’s a big enough deal to make me reconsider using Firefox, and I hope that there’s a public apology at the end of this and an end to the bad behavior.
In addition, I have used e-mail alias services in the past, with Bigfoot probably being the most common. They’re always a nightmare. You now have an extra server to worry about crashing. They all have opaque rules about which messages get thrown out. If you use it for actual correspondence—like technical support—you need to reconfigure your e-mail client to use the extra address. And when the company ultimately decides that it’s not cost-effective to keep providing the service, you need to update every address that you handed out.
A better solution is to either use a disposable e-mail address for disposable correspondence and use subaddressing with sign-ups that allow it. Then, you can add a filter so that any e-mail that you receive to
yourName+nameOfSuspiciousSite@yourServer.invalid gets whatever special processing that you think makes sense.
Not all systems recognize subaddresses as valid, and it often baffles support technicians, but it usually works well enough that I’ve started using them to narrow down the source of data breaches. If I see the name of a company in my e-mail address from spam or a leak, I know that account is no longer secure before the company announces it.
In any case, I’m unhappy that Mozilla has pulled this nonsense, especially in such a lazy way that every bad actor is going to figure out how to get around it immediately. This is going to wreak havoc on their reputation, as the tech podcasts go on the attack in the next couple of weeks. Most of them are already pro-Google, so this is definitely going to be everyone’s top story, along with plenty of smug “well, I support an open web, but I use Chrome, because it’s a quarter-percent faster when you have six thousand tabs open and is better at integrating with Google services…” comments.
Update: If you read down the issue thread, you’ll notice that someone did the research to discover that Mozilla Relay uses a service from Amazon, just as abusive and as much of a threat to privacy—especially through Ring—as Facebook. So, I’m going to strongly recommend that people do not take the add-on’s advice.
Other than updating some libraries, the big headline for Fýlakas Onomáton is that the name API now only works with a key, and separates responses by user, as identified with the API key.
Over in Doritís Onomáton, all requests now go to the same server—easily configured at the top, so that I can test locally, then eventually test against the deployed server—and now retrieves the key from local storage.
We’re getting there. It’s taking forever, but it’s edging closer to release.
Since I’ve started using Miniboost to write early drafts of future blog posts—it’s not ideal, for a variety of reasons, but the auto-preview features made it (basically) worth the nuisances—I decided to add a feature to allow users (me, specifically) to inject Font Awesome into documents.
The preview will now bring in the “kit” that’s tied to the user, so that I don’t need to care about versions or—worse—packaging Font Awesome with the application. Users sign up for their kit, then paste the provided line of code into to the configuration file as the
fontAwesomeKit key name.
And honestly, it doesn’t need to be Font Awesome. It’ll insert any code that you provide into the preview page’s HTML
I got derailed on Doritís Onomáton, a bit, so that needs to be the focus for the week. Specifically, the app needs to finish the authentication process, repeatedly checking the server for the API key or a time-out message. This probably means background processing. And I’ll tell you now that I’m not looking forward to it, since Flutter’s documentation just sends everybody to a blog post on Medium that only peripherally cares about threading.
I’d talk about other possible plans, but I think that the last few weeks have shown that “the Onomáton Suite” is going to get derailed by whatever I suddenly think of…
Credits: The header image is Pikillaqta by Håkan Svensson (Xauxa), released under the terms of the Creative Commons Attribution Share-Alike 3.0 Unported license.
Tags: programming project devjournal