I just hate that vendors got their hands on a standard designed to make auth more seamless and started adding in seams in hopes I use *their* preferred implementation and not anything else.

And it might also end up contributing to me dropping Bitwarden, because with the frequency I do something that results in my reinstalling the browser extension means I'm *incredibly* annoyed at their default-enabled passkey interdiction the settings for which I somehow always take a bit to find.

I've been using security keys since before the passkeys rollout and it absolutely fucked the UX and caused me to *reduce* my usage of webauthn.

Not to mention the MS UX idiocy was a non-trivial contributing factor to my significant reduction in Windows usage.

Their 2011 constitution was passed when Fidesz had over 2/3 majority and gives it a lot of weight, not only requiring it for some acts (including taxes and family policy), but also excluding regulation passed by supermajority from judicial review. And, well, it allows for altering the constitution.

WebUSB also has that: developer.mozilla.org/en-US/docs/W...

But it also only applies to "paired" (previously given permission to connect for this site) devices

And if you're fingerprinting via an API that requires explicit permission you can also ask for location or even filesystem access.

Quickly checking even if no devices match the given filter Chrome gives user the permission prompt - with just that info, but it should only resolve once closed. So I don't think you can even try checking what isn't connected.

What are the fingerprint concerns though? Firefox already sends a less common fingerprint by not supporting it.

I'm pretty sure the API itself doesn't actually expose any info without a permission to specific devices being given by the user.

The neat part about the first solution is that it works with other built in falsy objects too, so you can do it with Number and use NaN or 0, or with Boolean and make x just false.

They have it on repo level (as go to file, separate search box) and the search bar supports `path:` filter which I think can use globs.

IIRC they do implement Web Key Directory, so if the recipient had WKD set up proton would find the key and allow you to encrypt the message without setup.

But there are very few (the second largest one after Proton being mailbox.org, and I don't think it's enabled by default there) who support it.

(I'll need to look into MLS more, but from a cursory understanding it should be fairly easy to "break" its forward secrecy for this kind of purpose by saving the initial epoch secrets, but I may be wrong about how resilient forward secrecy within epochs is there. I've not found any attempts though)

(because as mentioned you can recover future messages from early state and each client stores the earliest room keys they know...)

So e.g. if Matrix adopts some other encryption scheme, like most likely MLS, if they want to still have this kind of history sharing mechanism they'll have to weaken it

It has... pretty much no backward secrecy (the only way to prevent a device from reading future messages is rotating your session key and sharing it with everyone, which doesn't happen often by design), limited forward secrecy (stopping session compromise from reading past messages)

So in theory once it's implemented (it is already in element web and element x apparently) you should just have all the keys to old messages just after joining a room

Also, notably, this is only possible because Matrix's group E2EE is a lot more limited compared to Signal or even the 1-to-1 version

After reading the newer solution (MSC4268) it seems like it should work better - since it basically frontloads all the work, by having inviter create a full bundle of shared keys they know and essentially send it as an encrypted attachment to each of invitee's verified devices

(so a malicious homeserver could add a device to your account and because the spec didn't even require device verification it could get all these shared keys)

And also, it meant the user who invited you had to be online to send you the keys when you browsed the history or no decryption for you...

And then after joining when you device saw a message it couldn't decrypt it would ask the user who invited them for the older session keys and if they knew them they'd share.

It's honestly a problematic solution because actually each device needs to ask for keys and it turns out user != device

(and each session is not used indefinitely, but replaced on several events - e.g. someone leaving a room)

So from my understanding the old solution (that I apparently missed was entirely withdrawn and that's why it doesn't work) was to add a marking to session keys in rooms with shared history

Pretty much, in Megolm there isn't a global room key, but rather each user creates a session which has a room key that's used to derive per-message keys (and it's a ratchet, so knowing it's current value you can derive future keys but not past ones), and shares that with each device in the group

Hmm... Apologies to Matrix people, I thought I had enabled this toggle but it turns out I can't (I moved homeservers so maybe the new one doesn't support it?), so... Maybe it works if you're able to turn it on (and thinking about this again, people inviting you probably need it turned on too).

Does this work well in practice though? Well... I'm not sure if I haven't seen a correctly configured room or what, but I don't think I've experienced joining an encrypted room and seeing its history yet.

Maybe the WIP MSC4268 will fix this, but I'll believe it when I see it.

No, it's not impossible: Matrix in theory support* having old messages visible and sharing historical keys with newly joined users, so in theory it has everything to make e2ee rooms with history from before joining...

*or at least: a few clients support it, it's not a finished part of the protocol

There's even a lot of stuff that could be found by just running existing non-llm-based tools in ways that produce non-practical levels of false-positives and filtering them The big thing IMO is verifiability - which is something that is very much getting easier with improving abilities to use tools

I have seen a few bugs that I could say required a lot of creativity and luck to get to and I doubt existing LLMs would be able to get them even with a great test setup (iirc one was for example caused by a subtle compiler bug, so the tested code was actually correct!) but these are *extremely* rare

But like, even if we were at the wall when it comes to models, you can already automate finding so much low hanging fruit, and, well, even outside of the simplest options a lot of security issues are just about persistently exploring for common issues.

Similarly there's a lot of software that's just damn annoying to automate for different reasons and is somewhat detached from mainstream software engineering for one reason or another, so even though LLMs do get better at it it's not at the same level or pace as more general cases.

I think a big issue with the claims of "LLMs won't work for X" is that it's often stated about fairly wide fields. Will LLMs automate *all* vulnerability research? I'd bet on "no" and we'll be seeing "artisan vulns" even in the wild for a long time still.

Tenstorrent downgrades Blackhole p150 PCIe cards specs from 140 to 120 cores - VideoCardz.com Jim Keller's Tenstorrent has quietly downgraded its Blackhole P150a accelerators This does not happen often in the hardware space, especially for products

Tenstorrent downgrades Blackhole p150 PCIe cards specs from 140 to 120 cores

To cancel you need to go to kimi.com/settings (not the code dashboard) and then go to subscription, or directly to www.kimi.com/membership/s...

But yeah, I've not tested it much with code but from quick testing with more research-like tasks it seems more sycopathic than K2 unfortunately.