aleksejs

That sounds fun too!

Buried at the bottom of the article, my favorite thing about modern Lego kits:

One of the most intriguing features is unlocked when you press the ‘build together’ button on select sets in the app. This allows consumers to build a LEGO set as a team by delegating each builder a building task to complete.

My partner and I enjoy assembling Lego kits together, but with paper instructions parallelizing the work is pretty tricky (usually we end up alternating one person doing the actual assembly and the other picking out the correct parts for them). But with the LEGO Builder app, it dynamically generates two parallel sets of instructions. It works great even if you're working at different paces.

This is one of those software features that delights me both as a user and as an engineer. It probably was not that complex to implement (once they had the building steps in a machine-readable format), but it's a great use of its medium, something that you genuinely couldn't do without software.

The camera (even the regular model) does not have its own GPS receiver at all. It relies on a smartphone to transmit GPS coordinates over Bluetooth.

This is pretty common in modern cameras, presumably because most photographers expect to be able to turn their cameras on and off very rapidly, and it would be difficult to maintain a GPS fix with that usage pattern.

You can install a custom operating system on (a non-carrier-locked model of) every phone Google has ever made.

This is imperfect, as CAA record validation is not mandatory yet. But by March 2027 all the CAs a supposed to have support.

Is that true? My read of Section 1.2.1 in [1] suggests CAA checking has been mandatory since 2017‐09‐08.

[1] https://cabforum.org/working-groups/server/baseline-requirem...

The jabber.ru post referenced here presents clear evidence (in the section titled "Network") that the malicious actor was able to reroute traffic going to the legitimate jabber.ru server. An attacker in this position does not need an RCE to get a cert, they can just get one issued the normal way, because they do effectively control the IP address that the domain is pointing to.

The leasing company leases these cars to Uber drivers in NYC, who presumably did not get cut off.

It doesn't provide a useful security feature, but it does lock out competition very well.

This seems to presuppose that service providers using reCAPTCHA are either clueless idiots or actively expending resources and lowering their conversion rates to support the supposed Google/Apple duopoly. That does not strike me as a plausible claim.

TFA is authored by the developers of an alternative operating system that can be freely installed on every Google phone since Pixel 6.

It argues no such thing. Of the 20 instances of the word "interest", 19 are obviously referring to the interest that the IRS will charge you on your balance if you don't pay your taxes by the due date. The one remaining one is this:

Overpayment interest for the 2020–2023 disaster period.

and refers to the interest that the IRS will pay you if they owe you money (a refund) that they don't manage to return to you in a timely manner.

(All of this is explained on the main IRS website: https://www.irs.gov/payments/interest)

It's a cultural difference thing: https://russian.stackexchange.com/questions/13142/what-do-or...

How do you even begin to define what correctness means for the transformations if you have no formalized model of the thing you're transforming into?

The linked website and repository do not refer to the outputs as "verified C++". The use of that term in the submission title here seems misleading, and the Design Principles [1] document clarifies it is only the source (Rocq) programs that are formally verified. It seems far from obvious that the complex and ad-hoc syntactic transformations involved in translating them to C++ preserve the validity of the source proofs.

[1] https://github.com/bloomberg/crane/wiki/Design-Principles

I'm not sure why you take me for a JSON/JWT fan (I'm happy to agree they've had their own share of implementation bugs), or what that has to do with signature wrapping bugs in XML-DSig, which is what I've been talking about this entire time.

I am comfortable saying that, when designing a signature scheme, people should not want features that are known to consistently lead to catastrophic vulnerabilities.

That is not, in fact, the question. The whole point of storing signatures separately from the serialized bytes they sign is not having to rely on any properties of the serialization scheme. It does not matter whether your serialization is canonical or not if you don't need to parse the document before you've verified the signature on it. XML-DSig, to the contrary, requires that you parse the document, apply complex transformations to it, and then reserialize it before you can verify anything, which is what makes bugs like "oops the canonicalization method errored and now my library will accept a signature over the empty string as valid for any document" (https://portswigger.net/research/the-fragile-lock#void-canon...) possible.

Most of these attack vectors have been known for 10 years, and yet researchers keep finding bugs in major implementations to this day. Here's one from last week: https://portswigger.net/research/the-fragile-lock

How would you digitally sign a Json document and embed the signature in the document?

You would not, because that's exactly how you get these bugs. Fortunately serialization mechanisms, whether JSON or Protobuf or XML or anything else, turn structured data into strings of bytes, and signature schemes operate on strings of bytes, so you'll have a great time signing data _after_ serializing it.

God forbid you have an accident and you end up at the wrong hospital when the one down the road is in-network but the one they took you to is out-of-network and you wake up owing thousands of dollars.

If you examine the statement of benefits for your plan, you will find that it says something similar to this:

Emergency Services are covered at the in-network cost-sharing level as required by applicable state or federal law if services are received from a non participating (out-of-network) provider.

The member is responsible for applicable in-network cost-sharing amounts (any deductible, copay or coinsurance). The member is not responsible for any charges that may be made in excess of the allowable amount.

The focus on maps and gemini is hilarious. The first is literally the anti-use case,

It reminded me of the Wii U Street View app and the interview with its developers (at https://iwataasks.nintendo.com/interviews/wiiu/wii-street-u/...). They were going for the same sort of a vibe, though it's unclear to me how many people actually ended up having that much fun with it.

I'm not sure I follow your point: how would a web service provider use a user's TPM in a pre-DBSC world? "Use hardware based attestation to tie the session token/cookie to the device" is pretty much exactly what DBSC does.

DBSC is intended to be deployed opportunistically alongside regular cookies, so users on devices without TPMs just won't benefit from the additional protections that DBSC provides.

This is neat! We're building something similar at work, but instead of hand-rolling specific checks (like "first signature must be direct child of Response" in samlshield) we're fingerprinting the structure of the SAML response and checking if it matches what we've previously seen from that IdP. We figured that would be more likely to catch any exploitation attempts we didn't anticipate while giving us some flexibility to not have to hardcode specific IdP behaviors. Having specific hard checks seems really valuable too, though, especially for applications that might not have many SAML responses to backtest on. And kudos for sharing a great corpus of test cases!

One thing that would worry me when deploying this in the Proxy mode is that you'll likely end up with two different XML parsers in play: xmldom in samlshield and then whatever the actual application is using. As we saw with CVE-2025-25292, it may be possible to exploit different parser behavior to construct a document that will be interpreted differently between the two applications, potentially bypassing the checks in samlshield.

For a high value account, a motivated attacker can and will continue at this point. (And if you don't consider your accounts high value, why are you bothering with 2FA?).

Because credential stuffing is highly lucrative, even when no individual account is particularly high value, and is the most common way accounts are compromised on most services. There are other things a _user_ might do to prevent credential stuffing, like using unique passwords, but 2FA has the benefit of actually being visible/verifiable for you as a service provider.

Duolingo | Pittsburgh, PA, USA | ONSITE, VISA | Security Engineer

Duolingo is the most popular language-learning application in the world, with over 500 million users and over half a billion exercises completed daily. Beyond our core learning product, we have also entered into literacy with Duolingo ABC and English proficiency testing with the Duolingo English Test. Our mission at Duolingo is to develop the best education in the world and make it universally available.

Our security team is growing and we are looking for engineers with experience in AppSec and CloudSec. We are running a microservice architecture on AWS and GCP, managed with Terraform, which supports our multiple web applications, mobile apps on Android and iOS, and a desktop Electron app.

Apply here: https://boards.greenhouse.io/duolingo/jobs/5392230002

Duolingo | Pittsburgh, PA, USA | ONSITE, VISA | Security Engineer

Duolingo is the most popular language-learning application in the world, with over 500 million users and over half a billion exercises completed daily. Beyond our core learning product, we have also entered into literacy with Duolingo ABC and English proficiency testing with the Duolingo English Test. Our mission at Duolingo is to develop the best education in the world and make it universally available.

Our security team is growing and we are looking for engineers with experience in AppSec and CloudSec. We are running a microservice architecture on AWS and GCP, managed with Terraform, which supports our multiple web applications, mobile apps on Android and iOS, and a desktop Electron app.

Apply here: https://boards.greenhouse.io/duolingo/jobs/5392230002

Duolingo | Pittsburgh, PA, USA | ONSITE, VISA | Security Engineer

Duolingo is the most popular language-learning application in the world, with over 500 million users and over half a billion exercises completed daily. Beyond our core learning product, we have also entered into literacy with Duolingo ABC and English proficiency testing with the Duolingo English Test. Our mission at Duolingo is to develop the best education in the world and make it universally available.

Our security team is growing and we are looking for engineers with experience in AppSec and CloudSec. We are running a microservice architecture on AWS and GCP, managed with Terraform, which supports our multiple web applications, mobile apps on Android and iOS, and a desktop Electron app.

Apply here: https://boards.greenhouse.io/duolingo/jobs/5392230002