akdev1l

hence why passkeys were ideally device specific, non-exportable

Not true. The original concept was always for them to be cloud synced.

This has nothing to do with their anti-phishing capabilities. The anti-phishing capabilities come from the fact that the password manager authenticates the application before handing out the passkey. It doesn’t matter if they are synced across devices or not.

You are correct that other login methods might be weaker than passkeys. I’m not sure how that’s related to passkeys though. In real security sensitive applications the recovery process is “go to the bank’s branch and show them your driver’s license”.

Your master password to your cloud PW manager's vault is also phishable

No, it’s not. You would need to steal my yubikey to get access.

Some functionality is not supported via USB-C. Namely HMAC Challenge does not work via usb-c but will work via lighting port.

By still having the password the user can still be attacked via phishing

Yes they have biometric collection stations now.

Rube Goldberg machine attached with used bubble gum and somehow the bubblegum was chewed in all the wrong ways

Not even tests but just some basic anomaly detection lol.

Like maybe if the bill amounts increase by like 10M% there should be someone that looks into it

Umm my toaster doesn’t have this problem and it’s not AI …

why does this happen to you?

If you put AI on a project the average consumer will think it’s using ChatGPT or something like that

I mean I agree with you just that the popular perception of that word has changed

Flathub only reviews the manifest.

If your manifest is covertly injecting malware into the build it could be easily missed. Consider some of the manifests are simply downloading deb packages and unzipping them.

The canonical answer to any concerns with the AUR is always “just read the PKGBUILDs bro”

LMAO brother you should stop projecting and get little more self assurance that isn’t tied to your wealth

I get my hair cut at a place where it costs $45 and I get a haircut every 1-2 months at best.

I wear my shoes until they break. I wear Vans Sk8 old skool high tops most of the time.

I am also on track to retire by 40 if all goes well. (Which is to say I don’t have THAT much money)

Why would you want people to think you're poor or cheap, except maybe when you're shopping for a car.

Personally, I don’t generally think about how other people perceive if I have money or not.

Technically linux. Not open source in its commercial forms.

You can brute force the real age this way.

Do binary search and you don’t even need that many calls.

1. Is person older than 50? 2. Older than 25? 3. Older than 18? 4. Older than 9? 5. Younger than 14? 6. Older than 16?

You could still have this 1-click experience with another system.

Like you could set some rule like “this vendor is approved for charges below $50”. We don’t need the legacy system for that.

(I don’t know if any payment systems can do that atm, just that if we wanted we could make them do that)

Visa seemed not to care too much about fraud though so at some level they do prefer ease of use over security

My biology teacher in school once tried to teach us that winds created by God. Not like spiritually or something but that God literally made the wind I guess.

My “earth sciences” teacher also once tried to argue with me against the universal law of gravitation. (no, she was not referring to Special/General Relativity. She didn’t agree two objects in a vacuum fall at the same speed regardless of mass.

As an anecdote, I provided fragnesia.c and the subsequent proposed patch to fix the issue and while it was not able to discover an entirely new vulnerability, I think it was able to find 2 new ways of exploiting the same underlying bug.

This is quite impressive considering I’m just a dumbass with a Claude subscription.

The JVM has nothing to do with Android. There is no JVM running android apps.

There was Dalvik VM at one point but now it’s just the Android Runtime.

A very comprehensive SELinux deployment for one.

SELinux will stop any process in android from loading kernel modules, that’s not allowed. The android permission model as a whole is ultimately backed by SELinux.

The thing is that we could simply split those modules into separate packages

No reason why you couldn’t just `dnf install -y kmod-rxrpc` if for whatever reason you need that.

interesting but in that case no point in keeping the x bit either and suid binaries should just be 4700 ?

F44 is safe as the kernel is greater than 6.18.22

Without read permissions you cannot execute the binary, that would not make any sense.

To execute the binary it needs to be read from disk and loaded into memory.

In fact if you have read permissions but not executable permissions on a specific binary then you can still execute it by calling the linker directly /bin/ld.so.1 /path/to/binary (the linker will read and load the binary and then jump to the entry point without an exec() call)

you dont test exploit pocs on your daily driver.

Do you just like making fake points and pretending other people said them?

what the blog says and what the code does are two different things.

For all I know the blog itself is a honey pot. I need to know what the code does before I run it.

Disagree because to run the PoC you really ought to understand what it’s doing.

And this code is not readable at all. It is failing at letting people confirm the exploit easily.

Agreed lmao the PoC itself looks like you’re getting attacked

Which I guess is true but I would like to verify the attack is the intended one

You’d have to reinstall the su binary itself I guess

No, Android doesn’t have suid binaries to exploit like in the PoC