| 00:31:23 | | etnguyen03 quits [Client Quit] |
| 01:01:48 | | teej joins |
| 01:12:27 | | benjins3_ joins |
| 01:15:42 | | etnguyen03 (etnguyen03) joins |
| 01:16:37 | | benjins3 quits [Ping timeout: 256 seconds] |
| 01:22:44 | | benjins3_ quits [Read error: Connection reset by peer] |
| 01:39:22 | | teej quits [Client Quit] |
| 01:41:16 | | PredatorIWD2 quits [Read error: Connection reset by peer] |
| 01:49:42 | | etnguyen03 quits [Client Quit] |
| 01:54:25 | <pabs> | Yubikey security updates: https://www.yubico.com/support/security-advisories/ysa-2024-03/ |
| 01:54:25 | <pabs> | it also applies to e-Passports, SIM cards and more: https://news.ycombinator.com/item?id=41438346 |
| 01:58:39 | <nicolas17> | "updates"? |
| 02:03:44 | <nulldata> | steering - probably not what you're thinking of but WordPress has a 100-year plan. https://wordpress.com/100-year/ |
| 02:06:10 | <pabs> | well, I guess no updates (like is usual for proprietary firmware), but security issues |
| 02:06:46 | <nicolas17> | the hardware doesn't allow for firmware updates by design |
| 02:07:05 | <pabs> | yay! |
| 02:07:21 | | pabs looks at his keyboard and wonders when it last got an update |
| 02:07:51 | <nicolas17> | also, people on hackernews had some pretty convincing arguments that: if you manage to steal a yubikey, instead of doing this complicated side-channel attack, it's far easier to replace it with a non-functional yubikey |
| 02:08:16 | <nicolas17> | the owner will go "huh my yubikey stopped working" while you use the stolen one to login to all their accounts |
| 02:08:38 | <nicolas17> | instead of stealing it, side-channel-ing the keys out of it, and putting it back |
| 02:09:06 | <pabs> | right |
| 02:12:02 | <nicolas17> | oh, for something completely different |
| 02:12:04 | <nicolas17> | pabs: https://www.youtube.com/watch?v=mI0teN4hPYQ |
| 02:12:13 | <nicolas17> | Apple Watch comms reverse-engineered |
| 02:12:35 | <pabs> | nice |
| 02:13:15 | <nicolas17> | they have some questionable crypto, as usual |
| 02:13:29 | <nicolas17> | which doesn't matter because it's inside an IPSEC tunnel with proper crypto |
| 02:35:28 | | etnguyen03 (etnguyen03) joins |
| 02:36:52 | | etnguyen03 quits [Remote host closed the connection] |
| 02:53:14 | <@hook54321> | might be able to do something similar to what's done with nail polish in this to protect against that https://mullvad.net/en/help/how-tamper-protect-laptop |
| 02:54:28 | <@hook54321> | if a yubikey ever stops working someone could compare the pictures of the nail polish to confirm it's the same yubikey |
| 03:19:39 | | HP_Archivist quits [Remote host closed the connection] |
| 03:20:53 | | HP_Archivist (HP_Archivist) joins |
| 03:23:50 | | AlsoHP_Archivist joins |
| 03:27:40 | | HP_Archivist quits [Ping timeout: 255 seconds] |
| 03:40:57 | | HP_Archivist (HP_Archivist) joins |
| 03:43:25 | | AlsoHP_Archivist quits [Ping timeout: 255 seconds] |
| 04:30:00 | <steering> | nulldata: oooh, I might actually trust wordpress to fulfill that |
| 04:34:49 | <steering> | I'm glad my gpg keys are all still RSA :'D |
| 05:56:56 | | Jens quits [] |
| 05:57:42 | | Jens (JensRex) joins |
| 06:21:55 | | BlueMaxima quits [Read error: Connection reset by peer] |
| 06:35:35 | | pabs quits [Read error: Connection reset by peer] |
| 06:36:18 | | pabs (pabs) joins |
| 06:41:18 | | pabs quits [Client Quit] |
| 06:41:47 | | pabs (pabs) joins |
| 08:11:26 | | BearFortress quits [Ping timeout: 256 seconds] |
| 08:26:01 | | godane quits [Ping timeout: 255 seconds] |
| 08:35:31 | | knecht quits [Quit: knecht] |
| 08:42:34 | | knecht (knecht) joins |
| 08:50:02 | | decky_e joins |
| 09:37:09 | <pabs> | huh, X let me read https://x.com/detahq without logging in (JS-enabled, Firefox) |
| 09:37:09 | <eggdrop> | nitter: https://nitter.lucabased.xyz/detahq |
| 10:41:43 | | BearFortress joins |
| 11:00:02 | | Bleo1826007227196 quits [Client Quit] |
| 11:01:22 | | Bleo1826007227196 joins |
| 11:09:22 | | neggles quits [Remote host closed the connection] |
| 11:09:29 | | oxtyped quits [Quit: ZNC - https://znc.in] |
| 11:09:51 | | oxtyped joins |
| 11:09:56 | | neggles (neggles) joins |
| 12:04:16 | | tzt quits [Ping timeout: 255 seconds] |
| 12:08:14 | | tzt (tzt) joins |
| 12:25:58 | | nulldata quits [Read error: Connection reset by peer] |
| 12:28:15 | | nulldata (nulldata) joins |
| 12:32:09 | <DigitalDragons> | were the tweets all really old? that's the behavior i've observed with profiles when logged out |
| 12:59:21 | | knecht quits [Quit: knecht] |
| 13:05:01 | | knecht (knecht) joins |
| 13:09:29 | | midou quits [Ping timeout: 256 seconds] |
| 13:13:28 | | midou joins |
| 13:30:08 | | threedeeitguy39 quits [Quit: The Lounge - https://thelounge.chat] |
| 13:46:10 | | knecht quits [Client Quit] |
| 13:53:25 | | threedeeitguy39 (threedeeitguy) joins |
| 14:04:06 | | BearFortress_ joins |
| 14:07:52 | | BearFortress quits [Ping timeout: 256 seconds] |
| 14:13:22 | | knecht (knecht) joins |
| 14:29:35 | | knecht quits [Client Quit] |
| 14:30:14 | | knecht (knecht) joins |
| 14:43:26 | <nicolas17> | old and in seemingly random order? |
| 15:24:23 | | lizardexile quits [Read error: Connection reset by peer] |
| 15:25:17 | | lizardexile joins |
| 17:00:14 | <@JAA> | Ordered by number of likes? |
| 17:09:24 | <DigitalDragons> | it seemed like some kind of rougher "popularity" metric to me but I might be misremembering |
| 17:50:22 | | nyakase (vukky) joins |
| 18:12:55 | <@OrIdow6> | That's what I recall being the case a few months ago, maybe they've changed it since |
| 18:21:57 | | threedeeitguy39 quits [Client Quit] |
| 18:36:20 | | @OrIdow6 quits [Remote host closed the connection] |
| 18:36:40 | | OrIdow6 (OrIdow6) joins |
| 18:36:40 | | @ChanServ sets mode: +o OrIdow6 |
| 18:37:36 | | IRC2DC quits [Ping timeout: 256 seconds] |
| 18:42:14 | | threedeeitguy39 (threedeeitguy) joins |
| 19:57:09 | | threedeeitguy39 quits [Client Quit] |
| 20:37:47 | | IRC2DC joins |
| 20:54:08 | | etnguyen03 (etnguyen03) joins |