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.
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.
> 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.
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.
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.
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.
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.