Notices by arcanicanis (arcanicanis@were.social), page 7
-
Embed this notice
arcanicanis (arcanicanis@were.social)'s status on Saturday, 14-Jan-2023 12:32:24 JST 
arcanicanis
and if the hardware attestation keys are dumped, congrats: the totality of damage you can do is just claim a new authenticator registration originated from a specific model of hardware, that's it. There's no damage in it beyond that from what I'm aware, as it serves no other role.
And if a key is dumped, then the service can just restrict any new authenticator device registrations of that batch/model, versus suddenly revoking all devices registered before the key was leaked (unless the time period of the leak is completely unknown to the span of years).
But yes, whitelist-only is a possible issue, but is unlikely for consumer services. -
Embed this notice
arcanicanis (arcanicanis@were.social)'s status on Saturday, 14-Jan-2023 11:53:57 JST
arcanicanis
and further on the communication and advocacy of FIDO2 is the absurdity where Microsoft tries to garner attention upon themselves for being a "pioneer" of the effort to "kill the password!". Where they keep using the term "passwordless authentication" which understandably should raise ire from any sysadmin, whereas apparently folks from Microsoft think they're playing some bigbrain 4D chess by using such wording, to get people to look into FIDO2, in clickbait-style tactics, when instead I believe it's scaring people away.
U2F/FIDO2 is a fairly interestingly minimalist and robust concept, versus the mess of PKCS standards with smartcard authentication and management, it's just that Microsoft (and some others) are really botching the messaging about it.
You can use FIDO2 authenticators for two-factor authentication, and you can certainly implement it as such in any of your applications/services. The problem is that some online services, such as crap like Azure, take an over-opinionated approach where your option is ONLY single-factor hardware authentication, which I was bitching about previously here: https://were.social/@arcanicanis/posts/AKQyHBW6ajXA0F468e -
Embed this notice
arcanicanis (arcanicanis@were.social)'s status on Saturday, 14-Jan-2023 11:42:47 JST
arcanicanis
> But the actual software being developed requires either spying device (aka smart phone) or worse, biometrics.
No. Not even remotely true.
In the simplest implementation (from what I remember, just in brief summary) of a U2F hardware token there are two storage components:
- Master key (or rather 'initial key', which is only generated once)
- Global signature counter
For 'registering' a U2F token for an account on an online service, the token is presented an RP ID (generally the protocol and domain part of the service authenticated to), and from that RP ID it derives a new private/public keypair (in-memory) from the stored master key, using a key derivation function, and presents the generated public key to the service. All these cryptographic operations happen internally on the token.
Then when authenticating to the same service, the RP ID is presented again along with a challenge to the token, the same private/public keypair is generated in-memory again, and creates a signature of the RP-provided challenge as well as the current 'signature counter' state, and returns the resulting signature (as well as the current 'signature count' it was signed with) to the service, while also internally incrementing the signature count by 1 in it's internal storage.
The service verifies if the signature matches up with the public key on record, and also makes sure that the 'signature count' is greater than the last time authenticated to the service. Otherwise if the signature count is the same as last time, or less than, then it would indicate a replay attack, and would be considered invalid.
In this scheme, there is a different public/private keypair for every service, yet within storage, it only has to remember one key, and has to keep a signature count.
Meanwhile, in further evolution into FIDO2, there's the addition of device attestation, whereas there's a separate private key and certificate burned into a batch of 100,000 tokens/devices of the exact same model, that is ONLY for a service to be able to verify the model and profile/capability of the token, as attested by it's manufacturer.
Each hardware vendor has their own root certificate that certifies the hardware attestation certificate burned into the token or cryptographic component. Hardware attestation is only relevant to appeal to government and financial sectors that require hardware certification, or to have authenticators from specific vendors or profiles. Hardware attestation is just an additional option presented that's not required for implementation in online services, it's just meant for organizations that want tighter control, for example: the US DoD could prohibit a DoD system from allowing some government contractor from registering a Hauwei-brand authenticator for their account. That's the intended use-case it's targeting with that addition. The attestation information is only presented upon registering an authenticator to an account for a service--and not used for any subsequent authentications.
As for biometrics and other components, that's all just internal to the implementation of the authentication token, of whether it wants to sign a challenge or not, and just being an advertised feature presented in the hardware attestation certificate, whereas it NEVER sends biometric information in any response.
https://fidoalliance.org/fido-technotes-the-truth-about-attestation/ -
Embed this notice
arcanicanis (arcanicanis@were.social)'s status on Friday, 06-Jan-2023 16:56:42 JST
arcanicanis
> A FOSS-Extremist will not tolerate the concept of people actually getting paid to work on commercial software in any spectrum of acceptance.
Depending on what you mean, it's actually not about money or commercial, the licensing is about user freedoms. You're free to sell free software, make a business off it, or anything for any commercial purpose:
https://www.gnu.org/philosophy/selling.en.html -
Embed this notice
arcanicanis (arcanicanis@were.social)'s status on Friday, 06-Jan-2023 16:47:09 JST
arcanicanis
Or set a check in icinga2 that checks specifically for a 200 response code, and searches for a string that's part of the expected body content. -
Embed this notice
arcanicanis (arcanicanis@were.social)'s status on Tuesday, 03-Jan-2023 14:49:16 JST
arcanicanis
I wouldn't say IPv6 is significantly complex; just that it's difficult at first with people who are so entrenched in thinking about everything in address scarcity than abundance, such as with subnetting. I've taught/trained Zoomers on networking in the military, by covering IPv4 and IPv6 simultaneously, and they didn't see IPv6 as much of a hurdle. In fact, subnetting is very often easier under IPv6, versus having to often use calculators for most allocations under IPv4. Meanwhile, when I was still in military (just a few years ago), networks were consistently being restructured from IPv4 addresses being shuffled around to skimp around scarcity and changes the size of various units. -
Embed this notice
arcanicanis (arcanicanis@were.social)'s status on Tuesday, 03-Jan-2023 14:14:35 JST
arcanicanis
3 out of the 4 US ISPs I've subscribed to in the past 5 years have provided service with CGNAT, and one other location that I had homeservers on fiber just switched to CGNAT less than two months ago:
- Boingo Internet (WISP, on most military bases) in different 3 states
- MetroNet (fiber), switched to CGNAT ~2 months ago
- and my current local ISP (that I'll not name, because it's a smaller ISP that would narrow down my location)
Spectrum/TWC was the exception, but wasn't available in some locations. -
Embed this notice
arcanicanis (arcanicanis@were.social)'s status on Tuesday, 03-Jan-2023 07:49:17 JST
arcanicanis
wat -
Embed this notice
arcanicanis (arcanicanis@were.social)'s status on Tuesday, 03-Jan-2023 07:47:32 JST
arcanicanis
Probably the most important keys on the keyboard, while I'd be fine if Caps Lock ever disappeared. Meanwhile I abhor the trend of things being dumbed down, like newer ChromeOS devices that I think omit either the Super key or Alt key, having narrowed arrow keys, and often omitting Home/End/PageUp/Down keys. It makes the hardware more useless for refurbing into a freer Linux netbook. -
Embed this notice
arcanicanis (arcanicanis@were.social)'s status on Sunday, 01-Jan-2023 11:24:30 JST
arcanicanis
I remember similar with Outlook/Hotmail: -
Embed this notice
arcanicanis (arcanicanis@were.social)'s status on Sunday, 01-Jan-2023 10:24:12 JST
arcanicanis
Just a routine Public Service Announcement from MeatCanyon:
https://odysee.com/@Meatcanyon:5/smelly-smash-bros:8 -
Embed this notice
arcanicanis (arcanicanis@were.social)'s status on Saturday, 31-Dec-2022 08:17:27 JST
arcanicanis
Except this is the exact scenario as marketing Linux: XMPP is a building block to federated messaging, just as Linux is a building block to an operating system. You don't very often see a heavyweight company advertising the concept of Linux-based operating systems to the public. There are marketing efforts such as one group doing the branding project of "Snikket", and there's also plenty of material being pushed out there, but nearly everyone instantly writes it off based upon their past experiences. Nearly everyone just chases after hype, new projects, new VC-funded platforms, and seldom bother with mature and non-controversial projects. Once hype faded, it's always attention diversion to "the next big thing" even though much of what's come about in recent years is just reinventing the same thing over and over again. -
Embed this notice
arcanicanis (arcanicanis@were.social)'s status on Saturday, 31-Dec-2022 08:04:40 JST
arcanicanis
The impression that I've been getting is as if Matrix was started by someone naively jumping into protocol design without much background in it. It's as if you asked a younger 'full-stack developer' to make a chat application, and they were trying to check all the boxes for -isms of the time (just transport JSON over HTTP/HTTPS instead of a purpose-built protocol, Comet-style communication, RESTful APIs, etc), as well as ignoring the warning of creating an overly state-dependent protocol.
There's still the major infancy of server implementations with the Matrix world, meanwhile in the XMPP world there's a selection of very mature and performant codebases which are actually quietly running very large high-availability workloads, just like with ejabberd running the notifications system for the Nintendo Switch user network, chat in EVE Online and Fortnite (https://xmpp.org/uses/gaming/) as well as in WhatsApp and Zoom (https://xmpp.org/uses/instant-messaging/), just unfortunately that these platforms choose to not federate likely over control and moderation concerns.
I remember the shitshow of the earlier years of Google Talk and Facebook Chat trying to steer XMPP usage solely within their interests, as well as the different mindset of chat protocols back then that understandably soured people's outlook on the protocol. I've been following and using Matrix from back when the webclient used to be hosted under the domain vector.im (and had an account under that domain), as well as the later rebranding of the client to Riot, and then Element. Matrix was trying to pitch the idea of account portability, true decentralization (not just federation), and other lofty goals, and I was hopeful to see something come of it. Instead we just have another glorified webchat with a RESTful API that federates and implements Double Ratchet, and it doesn't have that big of a sell (in terms of protocol architecture) over XMPP.
Meanwhile there's a lot of modernization that's happened within XMPP in just the past 5 years, but because of people's soured experiences from Google Talk from long ago, or Cisco's abomination in the corporate world, everyone still writes it off based on decade old experiences, or keeps repeating several years old complaints about XMPP on mobile, when that's completely changed since. Either way, everyone keeps showering Matrix with attention, as if it invented the idea of federated messaging, just like how people do the same with Mastodon instead of acknowledging any other fediverse platforms. -
Embed this notice
arcanicanis (arcanicanis@were.social)'s status on Friday, 30-Dec-2022 13:48:43 JST
arcanicanis
That is not "required by US federal law". I assume you're confusing with COPPA, which requires verified parental consent for a user under the age of 13 to register, if the platform performs data collection on users for commercial use or advertising. The platform could very easily limit registration to a much higher age if they so desired, and that wouldn't be 'illegal'. It's the pairing of allowing young users to register on a platform that could feature 'sex-positive' content (intentionally or mistakenly) is why people are criticizing it. -
Embed this notice
arcanicanis (arcanicanis@were.social)'s status on Friday, 30-Dec-2022 08:54:42 JST
arcanicanis
Only major bug I noticed with Steam under Wayland was that the Steam Chat window would render at like 1fps (or at least the textbox) if all the Steam windows weren't unminimized (in other words, if you had just the Steam Friends Chat thing open, but the main Steam window minimized, it'd horribly stutter). I've noticed this under a Wayland session of gnome-shell (mutter?) probably a few weeks ago.
Otherwise I'm still under an X11 session and weirdly I've had issues of Steam just going completely unresponsive any time of day in the background for the past week or two, when it hadn't before (I am on the Steam Client beta branch, to note).
Only still using an X11 session for being able to VR, as when I last tested SteamVR under Wayland it couldn't get exclusive access to the headset or whatever. -
Embed this notice
arcanicanis (arcanicanis@were.social)'s status on Thursday, 29-Dec-2022 11:54:20 JST
arcanicanis
Why can't there just be a simple D-Bus interface for pulling the 'currently playing ___ game' info (such from Steam, Lutris, whatever)? Or some other vendor-neutral API or minimal protocol for the same? Or perhaps some cross-vendor standard for sending multiplayer session invites?
Plenty of these seem like trivial ideas, and I understand there's probably many differing ways to implement such, but to my knowledge there's not a single project or standard within this field, from what I'm aware of.
I'm asking solely for technical reasons, I'm not asking about ideological explanations (since many of the answers for that are self-evident). -
Embed this notice
arcanicanis (arcanicanis@were.social)'s status on Thursday, 29-Dec-2022 11:05:17 JST
arcanicanis
For some reason I keep running into other Neos folks on fedi, than I've seen on any other platforms. I wonder if it's just a trend of Neos users usually using platforms based on technical merit, versus those that crowd to things only based on what's 'the most popular'. -
Embed this notice
arcanicanis (arcanicanis@were.social)'s status on Thursday, 29-Dec-2022 10:20:06 JST
arcanicanis
It's on my to-do list to explore writing an XMPP component server that attaches to Pleroma Chats; or at minimum: with the fedi backend that I'm quietly working on. -
Embed this notice
arcanicanis (arcanicanis@were.social)'s status on Tuesday, 27-Dec-2022 18:17:23 JST
arcanicanis
This is a pretty painless option to be able to capture application audio when screensharing on Discord from Linux (since Discord presumably ships a crap Electron runtime):
https://flathub.org/apps/details/de.shorsh.discord-screenaudio
Just requires a PipeWire sound server instead of PulseAudio. No need to manually create virtual sources and mux things together. -
Embed this notice
arcanicanis (arcanicanis@were.social)'s status on Tuesday, 27-Dec-2022 12:29:49 JST
arcanicanis
Protip: If you have the LUKS/dm-crypt tools installed, there is a benchmark tool that comes with it for checking your performance of different algorithms per the Linux kernel crypto API, by simply invoking cryptsetup benchmark. I just wish it also benchmarked some newer ciphers as well, like those used in WireGuard. Some examples of numbers:
Intel(R) Celeron(R) 2955U @ 1.40GHz (no AES extension support):
# Algorithm | Key | Encryption | Decryption aes-cbc 128b 86.8 MiB/s 101.8 MiB/s serpent-cbc 128b 36.3 MiB/s 114.8 MiB/s twofish-cbc 128b 72.2 MiB/s 109.4 MiB/s aes-cbc 256b 71.3 MiB/s 79.3 MiB/sAMD Ryzen 5 5600X 6-Core Processor (aes and vaes extensions):
# Algorithm | Key | Encryption | Decryption aes-cbc 128b 1458.4 MiB/s 5963.2 MiB/s serpent-cbc 128b 142.6 MiB/s 1007.5 MiB/s twofish-cbc 128b 276.7 MiB/s 504.2 MiB/s aes-cbc 256b 1080.3 MiB/s 5159.8 MiB/sSiFive Freedom U740 (HiFive Unmatched; no AES extensions):
# Algorithm | Key | Encryption | Decryption aes-cbc 128b 21.5 MiB/s 22.4 MiB/s serpent-cbc 128b 15.1 MiB/s 16.0 MiB/s twofish-cbc 128b 23.5 MiB/s 25.0 MiB/s aes-cbc 256b 17.2 MiB/s 17.8 MiB/s
All GNU social JP content and data are available under the