标签：#r

I have been working on Sesame, an open-source password manager that keeps your vault local by default. You don't need an account to create or use a vault, and the hosted service never receives the vault itself. It's still early software and the independent security review isn't finished yet, so I am mainly interested in feedback, testing, and people looking through the code. (Linux support is yet to be released on v0.1.2, but currently is in the works.)

Hi HN, I built Boop because I wanted application events sent directly to my phone without paying for another service or routing everything through Slack or Telegram. Boop is a small, open-source server paired with an open-source iOS app. The server currently uses around 8 MB of memory on my machine. It’s deliberately not an observability platform or a replacement for Sentry. It receives events from your applications, sends native push notifications, and keeps them in a purpose-built mobile inbox

Leaving a class open to inheritance is a design decision, not a default you can ignore. The core idea An unsealed class is a promise: every virtual member can be overridden without breaking what the class guarantees. Most classes never meant to make that promise. They're just unsealed by default, because that's what class gives you unless you say otherwise. Common mistake: treating sealed as "I don't want to think about subclassing" rather than "this type's invariants would break if someone could." One override breaks the promise Here's the promise, a BankAccount that refuses to go negative: public class BankAccount { public decimal Balance { get ; protected set ; } public virtual void Withdraw ( decimal amount ) { if ( amount > Balance ) throw new InvalidOperationException (); Balance -= amount ; } } And here's the override that breaks it: public class RiskyAccount : BankAccount { public override void Withdraw ( decimal amount ) { Balance -= amount ; // no check } } Nothing here is exotic. It compiles cleanly, and RiskyAccount is a perfectly legal BankAccount as far as the type system is concerned. Open one with a balance of 100 and withdraw 500: BankAccount account = new RiskyAccount ( 100m ); account . Withdraw ( 500m ); Console . WriteLine ( $"Balance: { account . Balance : F2 } " ); Real dotnet run output: Balance: -400.00 The check on the left never ran. virtual was an open invitation, and RiskyAccount took it. Sealing turns a silent bug into a compile error Without sealed , the code above compiles and produces a wrong answer at runtime; nothing points you at the problem until it's already in production. With sealed , the same mistake becomes something the compiler catches before the code ever runs: public sealed class BankAccount { public decimal Balance { get ; protected set ; } public void Withdraw ( decimal amount ) { if ( amount > Balance ) throw new InvalidOperationException (); Balance -= amount ; } } public class RiskyAccount : BankAccount { } // error

Stop paying just to take meeting notes Discussion | Link

Brave's browser begins testing an email alias feature that lets you keep your main email info private.

Welcome to the fifth article in our OWASP Mobile Top 10 2024 series! In previous articles we covered M1: Improper Credential Usage, M2: Inadequate Supply Chain Security, M3: Insecure Authentication/Authorization, and M4: Insufficient Input/Output Validation. Today we discuss why "we already use HTTPS" isn't a sufficient answer. Introduction M5 is the most misleading item on the list, because most teams read it and move on: "We use HTTPS, this doesn't apply to us." OWASP's definition is far broader. This risk covers all aspects of getting data from point A to point B, but doing it insecurely. It encompasses mobile-to-mobile communications, app-to-server communications, or mobile-to-something-else communications. It includes all communications technologies that a mobile device might use: TCP/IP, WiFi, Bluetooth/Bluetooth-LE, NFC, audio, infrared, GSM, 3G, SMS, etc. So M5 isn't just "do you use HTTPS." It's all of this: Whether you set up TLS correctly (certificate checking, cipher selection) Whether your traffic is consistent (some endpoints HTTPS, others not) What your third-party SDKs are doing What your WebView is loading What you send over alternate channels like push notifications and SMS 💡 Key point: Just because an app uses transport security protocols doesn't mean it's implemented correctly. HTTPS is not a checkbox; it's a system that must be configured properly. A specific situation for React Native developers In React Native the network layer lives in three separate places, and most developers only think about the first: The JavaScript side — fetch , axios , XMLHttpRequest Platform configuration — ATS on iOS, Network Security Config on Android Native modules and SDKs — analytics, ads, crash reporting, payment SDKs Whatever you do on the JavaScript side, if platform configuration is loose or a third-party SDK uses plaintext HTTP, your app is exposed. OWASP Assessment Metric Value Meaning Exploitability EASY A proxy and the same network is enough Prevalence CO

How to run internal phishing simulations for your organization (free & self-hosted) Phishing is still how most breaches start. The single most effective defence isn't another mail filter — it's people who can spot a lure and report it. The way you build that instinct is internal phishing simulations : controlled, authorized fake-phishing tests of your own employees, paired with training the moment someone slips. This is a practical guide to doing that well — and doing it for free, on your own infrastructure, with an open-source tool. First rule: authorization, always Internal phishing simulation means testing people who have agreed to be tested — your own organization, or a client with a signed engagement scope. Point a phishing tool at anyone outside that and you're very likely breaking the law. Keep a record of your authorization, tell leadership and (per your policy/works-council rules) employees that a program exists, and never use captured data for anything but the training exercise. Good tools are built as trainers , not credential-harvesters — for example, they don't store the passwords people type into a fake login page by default. With that ground rule set, here's what a real program looks like. A good program is a loop, not a single test "Who clicked?" is where most free tools stop. A program that actually reduces risk runs four stages: Attack — send a believable lure and track engagement per person. Report — make it one click for employees to report suspicious mail, and give them credit when they do. Train — the moment someone clicks or submits, teach them what they missed. Measure — roll it all up into a human-risk score you can trend over time. You can assemble this from separate tools, or use one platform. Below I'll use VoltPhish , an open-source, self-hosted platform that does the whole loop from one Docker container. (If you only need email click-tracking, GoPhish is the classic minimal option; commercial suites like KnowBe4 or Proofpoint do all of

Episode 2 | Spring Core | Understanding IoC, Dependency Injection & Beans In Episode 1, I covered the WHY behind Spring — tight coupling, and how Spring takes over creating and providing objects (IoC + DI) instead of classes creating their own dependencies. This episode picks up from there with the parts I hadn't covered yet: how Spring actually does that under the hood — Beans, the Spring Container, and Component Scanning. 🔑 Keywords → 🧠 Understand → 💡 Why? → 💻 Practice → 🎯 Interview Questions → 🛠️ Project 🔑 Keywords for This Episode IoC & Dependency Injection (quick recap) Spring Bean Spring Container / ApplicationContext Component Scanning 1️⃣ Quick Recap: IoC & Dependency Injection From Episode 1: instead of a class creating its own dependency — public class TicketService { private TicketRepository repository ; public TicketService () { repository = new TicketRepository (); } } — Spring creates the dependency and hands it to the class. That's Inversion of Control (IoC) . In code, this usually looks like a constructor parameter: public class TicketService { private final TicketRepository repository ; public TicketService ( TicketRepository repository ) { this . repository = repository ; } } TicketService no longer says "let me create a TicketRepository." It says "I need a TicketRepository" — and Spring supplies one. That act of supplying it is Dependency Injection (DI) . IoC = who's in control of creating/managing objects → Spring. DI = how a class actually receives what it needs → passed in, not self-created. That's the recap. Now — where do these objects Spring creates actually come from, and where do they live? 2️⃣ Spring Bean — what Spring actually manages When Spring creates and manages an object for you, that object is called a Bean . This is the vocabulary you'll see everywhere in Spring code and docs, so it's worth being precise about it. @Service public class TicketService { } The @Service annotation is a signal to Spring: "this class should be managed b

Un déploiement devrait être la chose la plus ennuyeuse de ta semaine. S'il est excitant, c'est mauvais signe. Au début de ma carrière, les mises en production étaient des événements. On retenait son souffle, on croisait les doigts, quelqu'un exécutait de mémoire une séquence d'étapes manuelles, et on regardait les journaux avec une boule au ventre. C'était palpitant. C'était aussi terrifiant, et le côté palpitant était précisément le problème : chaque déploiement était un pari, parce que chaque déploiement était un peu différent du précédent. Un bon déploiement est répétable. La même chose, de la même façon, à chaque fois — automatisée, pas récitée par un humain fatigué à la fin d'une longue journée. Quand le processus est un script plutôt qu'une cérémonie, l'ennui remplace l'angoisse. Tu ne pries plus. Tu appuies sur un bouton, et le résultat est prévisible parce qu'il a déjà été prévisible cent fois. L'automatisation fait ici plus que gagner du temps. Elle supprime toute une catégorie d'erreurs : l'étape oubliée, le mauvais paramètre, le « je croyais que tu l'avais fait ». La machine ne se fatigue pas, ne saute pas de ligne, ne se laisse pas distraire à mi-chemin. Elle rend le déploiement fiable au point d'en être ennuyeux — et l'ennui, en production, est un luxe. Alors, si tes mises en production font encore monter le rythme cardiaque, ce n'est pas de la prudence. C'est un signal. Rends-les répétables, rends-les automatiques, rends-les ennuyeuses. Garde le frisson pour ta vie ; ton système de production, lui, mérite l'ennui. – Serguey Shinder

Fire TV Sticks can last for years, but how many? Here's how to know when support ends for your device and when to upgrade.

Le maillon le plus faible de ta sécurité a un pouls. Ce n'est pas ton pare-feu, ni ton chiffrement, ni ton dernier correctif. C'est une personne — et les attaquants le savent bien mieux que la plupart des équipes. Pourquoi forcer une porte blindée quand on peut simplement demander la clé ? La majorité des intrusions sérieuses ne commencent pas par un exploit technique génial. Elles commencent par un e-mail qui a l'air juste assez vrai, un appel qui semble venir du service informatique, une pièce jointe qu'une personne pressée ouvre sans réfléchir. La technologie tient. C'est l'humain qu'on contourne. Cela dérange, parce que c'est plus difficile à corriger qu'une faille logicielle. On ne corrige pas les gens. Mais on peut les préparer. La formation ne consiste pas à traiter les employés d'imprudents ; elle consiste à leur montrer à quoi ressemble vraiment une attaque, pour qu'ils la reconnaissent dans un moment de fatigue. Et il faut concevoir en supposant que quelqu'un se fera avoir un jour. Parce que quelqu'un se fera avoir. L'authentification à plusieurs facteurs, le moindre privilège, la limitation de ce qu'un compte compromis peut atteindre : tout cela existe précisément parce qu'un humain finira par cliquer sur le mauvais lien. La question n'est pas si, mais quand — et ce qui reste debout après. Alors ne consacre pas tout ton budget aux murs et rien aux personnes qui gardent les portes. Le maillon le plus faible a un pouls, un mauvais jour, et une boîte de réception pleine. Protège-le comme le reste de ton infrastructure, parce que c'en est la partie la plus exposée. – Serguey Shinder