@CryptoLek Interesting. I had a thought, I did not read the RF report yet. Did they look for unique passwords and cross reference them with other data sources? Could that maybe identify people who reuse their password?

I was wondering if a simple way would be to look them up against the HIPB password dataset to get an idea of if there is any overlap. Then again, HIPB is designed to tell you if a password is bad, not if it's good (unique or rare).

@harrysintonen the fact that HackerOne hasn't banned this user (and many others!) after the first obviously bullshit report is what I'm concerned about. If they're allowing these folks to attack projects like this, they aren't doing what they're paid to do. The long-term credibility of researchers on the platform is the only value HackerOne brings to the table.

Why does the #AISlop problem exist at #hackerone (and likely other bug bounty platforms)?

Because apparently it works: https://hackerone.com/evilginx/hacktivity?type=user

It seems that some projects pay bounties for such AI Slop reports.

Finally caught up with my mastodon feed. Seems I have let it grow too big again, need to prune.

It's be very useful if @ivory would have display filters that would allow me to show only things with N stars or M re-toots so I could quickly get back on track when I get behind.

If anyone is confused with what I'm saying, I recommend reading my blog about how I consume SoMe. I personally find it to be the best and probably healthiest way. But your mileage might vary depending on what you use it for.

https://blog.nyman.re/2023/01/27/the-lifters-guide.html

The EU is introducing an energy label for phones, together with mandatory requirements for phones sold in the EU;

- 5 years of software updates (AFTER they stop selling the device in the EU)

- providing important hardware parts (during sale and for 7 years after), including free software (if needed), to every repair shop, within 5-10 business days

- batteries have to make 800 charging cycles and still be above 80% original capacity

And on top of that, phones and tablets need this energy label (which also includes a fall damage durability and repairability score), and abide by the above requirements, from 20 June 2025.

(https://energy-efficient-products.ec.europa.eu/product-list/smartphones-and-tablets_en)

The 2025 Mandiant M-Trends report is here. First the first time in the history of the report, global dwell time has increased, albeit only one day, from 10 to 11 days. This is still worrying, as ransom actor extortion demands have pressured the dwell time downward, but for an obviously bad reason. Global detection by source has also moved in the wrong direction, with slightly more external vs internal detection. I fear we have entered the realm of decreasing “returns on security investment,” especially for the security 1-10%.

It's time again for the yearly renewal prompted noscript.it advert.

I moved it off Gandi and to Netim so saved a few bucks, thus the ad will be shorter :-)

Anyways, please check out https://noscript.it for all your noscript-linking.

#noscript

@dmnelson @durumcrustulum hopefully, it was just something I thought today. It feels like there are more vulnerabilities for iOS nowadays. New patch every other week.

And that's on the most secure platform in the world which has every anti-exploitation technique imaginable and then a few more.

Durov threatens to leave France: Telegram founder and CEO Pavel Durov has taken a page out of Signal's book and says he'll pull the app out of France if officials demand an encryption backdoor.

Why would he be worried about a backdoor when the front door is wide open?
The only pretense of e2e in Telegram is at the bottom of a filing cabinet, in a disused lavatory; with a sign on the door saying 'Beware of the Leopard.'

I'm really wondering if syncable passkeys will turn out to be a mistake in the end.

For now it's a big improvement for almost everybody for now. But I'm wondering it's a question of time until the attackers catch up and figure out how to extract them, and then we're back where we started?

I love passkeys, but I'm really vary of storing all my eggs in one basket but everyone and their cousin is adding syncable passkey support to the password manager which makes the UX of keeping things separate really annoying.

And since the introduction of native webauthn support and then passkeys I have lost the ability to use the SEP as a non-syncable storage https://github.com/github/SoftU2F

I really liked how the keymaterial was locked into the SEP and "impossible" to export. But it was accessible with a simple TouchID.

While Apple does a lot of fancy stuff with SKP, it feels like that's so complex it can't be as secure.

Maybe something for @durumcrustulum and #scwpod ? The question being, does apple have some fancy crypto setup which makes extracting the passkeys uneconomical. How about the fact that I can unlock it with my N-pin passcode. Can I extract the keymaterial with that or only interact with it and get it to sign things for me?

Either way, I guess I won't be able to get rid of my Yubikey for a while still.

#passkeys #softu2f

@DurableAce DeepL is in my experience as good as Google translate or better on the languages I translate, both makes mistakes.

@ceiron @ueeu @marcel_kolaja @echo_pbreyer Install a compatible translate app (for example DeepL), go to settings -> apps -> default apps -> translation

It was introduced in 18.4 I believe, not sure if it's region restricted

PSA, you can now change the default translation app in iOS thus finally giving you the ability to translate highlighted text also in the languages Apple has not bothered with.

Also an opportunity to #EUAlternatives if you switch to DeepL , which is the only app I've found so far that supports being the default translation app, maybe @ueeu knows more.

Thank you @marcel_kolaja @echo_pbreyer and everyone else who made this happen.

#apple #eu #dma

Happy Birthday AltStore PAL!! 🎉🎂

PAL launched 1 year ago today, so to celebrate we’re bringing back a Classic… AltStore Classic!

Download AltStore Classic in AltStore PAL to sideload 100s of “non-notarized” apps, including some favorites that use JIT like DolphiniOS 🐬

@zackwhittaker I don't understand how TAG can find these things which Apple can't (or does not want to)? Do they have special introspection capabilities on iOS that nobody else has?

Maybe they find odd network traffic and then go pull apart the phone.

@riskybusiness @campuscodi

Ok I'll walk back from the hallucination idea for now, I actually reached out to DTC to ask about this, and they said the number comes from Tom Meur himself. So I guess next step is to reach out to him directly.

This caught my eye on the latest @riskybusiness newsletter by @campuscodi

It quotes a PR piece by the Dutch Digital Trust Centre, and the newsletter says

The same study also found that in 95 out of 100 cases, companies were forced to pay the ransom or go bankrupt.

I have two questions about this. First and most importantly I'm trying to understand where they got that number from.

The study they refer to is a PhD by Tom Meurs which is available in English.

But having looked at that PhD I cannot find anything which would support those numbers. The only reference about companies paying to avoid bankruptcy is a reference to another study which found that 8 out of the 41 (20%) of organisations they interviewed said they to avoid bankruptcy.

I have not read that in detail but I would assume that in a interview, people would want to say they paid because they had to as paying is frowned upon.

The other question is for Catalin and Patrick. When I translate it, I get

Meurs' research shows that companies often have no choice but to pay a ransom: "In roughly 5 out of 100 cases where a ransom is paid, victims do have the option of recovering by other means than paying, but choose to pay anyway - for example, to recover faster or avoid reputation damage. In the remaining 95 cases, there is no other option to recover. In those cases, their entire IT infrastructure is broken and unrecoverable, making paying a ransom the only option to avoid bankruptcy."

Even if we trust the number, I think there is a key difference lost in the newsletter. It says among those who paid, 95% said it was because they had no option. Not that 95% had no option but to pay or risk bankruptcy.

But I just came up with another idea of where that number is from. 95 and 5 sound suspiciously like confidence and p values, which makes me suspect someone fed that PhD into a LLM and it hallucinated that number and summary.

Until someone points me at an actual source for that number I will treat it with a lot of skepticism.

[Edit: linked to and corrected the author source, while the author of the PhD works for the police, the article linked in the newsletter is published by the "Digital Trust Centre"]
[Edit 2: Small clarification]

But Gabriel, how do we know what “actual security” is?

Well, thats a longer thread but I would start with PRAGMATIC THREAT MODELING (e.g. not the academic or compliance fluff).

Sit down and think about the threats. If you don’t know what threats you have, just start with ransomware and work backwards because thats a universal threat to anyone who has anything connected to the internet.

It’s of course more complicated than that (wouldn’t it be fun if this was easy and we’d all be out of work?) but that will be for another time.

I think it’s worth reading the full thread from @Viss but I want to highlight this part.

I’ll admit I might just be liking this part because it gives me validation for how I have approached things. But I think there is something really important in here.

There is a limit to the amount of resources we have, and anything you spend on filling out papers and drafting policies is away from working on actual security.
https://mastodon.social/@Viss/114345169329315004

and so in my experience, (i started this nonsense professionally in 2009), i have seen that when a shop is given "no actual rules to follow" - they are, most of the time (probably 60-70% by my measure)

WAY WAY WAY BETTER AT SECURITY.