mafriese
Joined 7 years ago
Karma
215
Submissions
34
Member since
May 9
Meow
View on Hacker NewsRecent submissions
Comment · 5 months ago
I posted a comment on the announcement when it was posted here:
>As someone who is working in incident response and malware analysis I have to say that is one of the worst ideas I have ever seen. A lot of companies have issues with ClickFix [1] and other social engineering campaigns and now Google wants to teach users that they should scan QR codes to proceed on a website.
>How should we realistically teach Susan from HR the difference between a real Google Captcha QR code and a malicious phishing QR code - you (realistically) can't. I wish we could - but those people don't work in tech, they will never know and I can't really blame them because at the end of the day they are just happy that they don't have to deal with tech after work.
>We have spent years of behavioural conditioning to prevent QR-code based phishing attacks (some people call it Quishing but I hate that term) and since the QR code is being scanned from a mobile device (99.99% of the time the private device), we have no EDR visibility on those devices and can't track what's happening if people scan it.
>This is more of an invitation for threat actors than it is something that holds them back.
Comment · 5 months ago
As someone who is working in incident response and malware analysis I have to say that is one of the worst ideas I have ever seen.
A lot of companies have issues with ClickFix [1] and other social engineering campaigns and now Google wants to teach users that they should scan QR codes to proceed on a website.
How should we realistically teach Susan from HR the difference between a real Google Captcha QR code and a malicious phishing QR code - you (realistically) can't. I wish we could - but those people don't work in tech, they will never know and I can't really blame them because at the end of the day they are just happy that they don't have to deal with tech after work.
We have spent years of behavioural conditioning to prevent QR-code based phishing attacks (some people call it Quishing but I hate that term) and since the QR code is being scanned from a mobile device (99.99% of the time the private device), we have no EDR visibility on those devices and can't track what's happening if people scan it.
This is more of an invitation for threat actors than it is something that holds them back.
Comment · 6 months ago
From my experience OpenAI has become very sensitive when it comes to using their tools for security research.
I am using MCP servers for tools like IDA Pro or Ghidra (for malware analysis) and recently received a warning:
> OpenAI's terms and policies restrict the use of our services in a number of areas. We have identified activity in your OpenAI account that is not permitted under our policies for: - Cyber Abuse
I raised an appeal which got denied. To be fair I think it's close to impossible for someone that is looking at the chat history to differenciate between legitimate research and malicious intent. I have also applied for the security research program that OpenAI is offering but didn't get any reply on that.
Comment · 8 months ago
I’m not saying that this is related to Wikipedia ditching archive.is but timing in combination with Russian messages is at least…weird.
Comment · 8 months ago
From the conclusion
> Importantly, this work also highlights the defensive implications of such techniques. While Secure Boot and firmware integrity mechanisms would prevent this attack chain when correctly enforced, the explicit requirement for users to disable Secure Boot demonstrates how social and usability tradeoffs continue to undermine otherwise effective platform defenses.
Comment · 9 months ago
maybe it's a mix of both :)
Comment · 9 months ago
You can define the tools that agents are allowed to use in the opencode.json (also works for MCP tools I think).
Here’s my config: https://pastebin.com/PkaYAfsn
The models can call each other if you reference them using @username.
This is the .md file for the manager : https://pastebin.com/vcf5sVfz
I hope that helped!
Comment · 9 months ago
Nope it isn’t. I did it as a joke initially (I also had a version where every 2 stories there was a meeting and if a someone underperformed it would get fired).
I think there are multiple reasons why it actually works so well:
- I built a system where context (+ the current state + goal) is properly structured and coding agents only get the information they actually need and nothing more. You wouldn’t let your product manager develop your backend and I gave the backend dev only do the things it is supposed to and nothing more. If an agent crashes (or quota limits are reached), the agents can continue exactly where the other agents left off.
- Agents are ”fighting against” each other to some extend? The Architect tries to design while the CAB tries to reject.
- Granular control. I wouldn’t call “the manager” _a deterministic state machine that is calling probabilistic functions_ but that’s to some extent what it is? The manager has clearly defined tasks (like “if file is in 01_design —> Call Architect)
Here’s one example of an agent log after a feature has been implemented from one of the older codebases: https://pastebin.com/7ySJL5Rg
Comment · 9 months ago
Ok it might sound crazy but I actually got the best quality of code (completely ignoring that the cost is likely 10x more) by having a full “project team” using opencode with multiple sub agents which are all managed by a single Opus instance. I gave them the task to port a legacy Java server to C# .NET 10. 9 agents, 7-stage Kanban with isolated Git Worktrees.
Manager (Claude Opus 4.5): Global event loop that wakes up specific agents based on folder (Kanban) state.
Product Owner (Claude Opus 4.5): Strategy. Cuts scope creep
Scrum Master (Opus 4.5): Prioritizes backlog and assigns tickets to technical agents.
Architect (Sonnet 4.5): Design only. Writes specs/interfaces, never implementation.
Archaeologist (Grok-Free): Lazy-loaded. Only reads legacy Java decompilation when Architect hits a doc gap.
CAB (Opus 4.5): The Bouncer. Rejects features at Design phase (Gate 1) and Code phase (Gate 2).
Dev Pair (Sonnet 4.5 + Haiku 4.5): AD-TDD loop. Junior (Haiku) writes failing NUnit tests; Senior (Sonnet) fixes them.
Librarian (Gemini 2.5): Maintains "As-Built" docs and triggers sprint retrospectives.
You might ask yourself the question “isn’t this extremely unnecessary?” and the answer is most likely _yes_. But I never had this much fun watching AI agents at work (especially when CAB rejects implementations). This was an early version of the process that the AI agents are following (I didn’t update it since it was only for me anyway): https://imgur.com/a/rdEBU5I
Comment · 1 year ago
I am still torn on this issue. On the one hand, it feels like a copyright violation when other people's works are used to train an ML model. On the other hand, it is not a copyright infringement if I paint a picture in the Studio Ghibli style myself. The question is whether removing a ‘skill requirement’ for replication is sufficient grounds to determine a violation.
Comment · 1 year ago
I never doubted that it's possible but it's way harder than identifying bank accounts.
There is a massive business behind crypto tracking, that's why companies like MasterCard have acquired CipherTrace. Some years ago there was a really good article / case study from them. I think it was related to a ransomware gang and they were able to identify the threat actor's wallets through crypto tumblers and chain hopping.
It's just a matter of how much money and time are you willing to invest into finding out and not a matter of possibility.
Comment · 1 year ago
You can easily establish the connection from a bank account to a person. A connection from a crypto wallet to a person is extremely difficult.
Money laundering with crypto is also much easier (and cheaper usually).
Comment · 1 year ago
> The threat actor appears to have obtained this information by paying multiple contractors or employees working in support roles outside the United States to collect information from internal Coinbase systems to which they had access in order to perform their job responsibilities
Based on the information present in the breach, I think it's likely that the source was their customer support in the Philippines. Monthly salary is usually < 1000$/month (entry-level probably even less than 500$) and a 5000$ bribe could be more than a year worth of money, tax-free. Considering the money you can make with that dataset now, this is just a small investment.
> •Name, address, phone, and email; •Masked Social Security (last 4 digits only); •Masked bank-account numbers and some bank account identifiers; •Government‑ID images (e.g., driver’s license, passport); •Account data (balance snapshots and transaction history); and •Limited corporate data (including documents, training material, and communications available to support agents).
This is every threat actor's dream. Even if you only had email addresses and account balances, this is a nightmare. Instead of blackmailing the company, you can now blackmail each individual user. "Send me 50% of your BTC and I won't publish all of your information on the internet". My guess is that we will have a similar situation like we had with the Vastaamo data breach...