twiss

FIPS-140 doesn't yet require PQC, nor does Go in FIPS mode (or any other mode).

So, if you only want PQC, you'll have to do that manually either way. But, I think you'll find many servers aren't ready for that: https://www.netmeister.org/blog/pqc-use-2026-09.html

Yeah. Also, IANAL but even if the European Commission does think Apple's interpretation of the DMA is reasonable, Apple could still be sued by an affected company or person, and a judge might disagree, IIUC: https://bureaubrandeis.com/private-enforcement-of-the-dma-a-...

Support period != warranty period. The OnePlus 15 will get 4 years of Android updates and 6 years of security patches.

I think this is more common when reporting heights in feet+inches than in cm. Rounding up 1.76m to 1.80m seems much weirder than rounding up 5'11" to 6', since all measurements in cm are very precise-sounding.

Why do you think being regulated utilities would preclude having multiple classes of service? Airlines had first class before deregulation: https://en.wikipedia.org/wiki/First_class_(aviation)#History

In Celcius, it's less common to round to the nearest 10 degrees (or say things like "in the twenties" as you might with Fahrenheit), because that makes a much larger difference than it does in Fahrenheit. So I wouldn't necessarily assume that "20 degrees" only has one significant digit unless it's explicitly stated. (I haven't checked the original paper, though.)

However, converting something like 21°C to 69.8°F is indeed silly and should just be 70°F.

Do we know that those heavy duty trucks were formerly used to do things you need heavy duty trucks for? It seems more likely that 18% (or more!) of the usage was by people who think heavy duty trucks look cool and wanted to show off theirs.

There are, in fact, some efforts going on to improve beyond the status quo on permission prompts in browsers, e.g. https://chromium.googlesource.com/chromium/src/+/refs/heads/...

Though, that document also states:

> Our research [1] finds that users often make rational decisions on the most used capabilities on the web today — notifications, geolocation, camera, and microphone. All of them have in common that there is little uncertainty about how these capabilities can be abused. In user interviews, we find that people have clear understanding of abuse potentials: notifications can be very annoying; geolocation can be used to track where one was and thus make more money off ads; and camera and microphone can be obviously used to spy on one’s life. Even though there might be even worse abuse scenarios, users aren't entirely clueless what could possibly go wrong.

[1]: https://dl.acm.org/doi/10.1145/3613904.3642252

Spec: https://www.w3.org/TR/css-values-5/#randomness

WPT test results: https://wpt.fyi/results/css/css-values?label=master&label=ex...

Only Safari supports it for now, it seems.

The actual number is 23: https://en.wikipedia.org/wiki/Birthday_problem

The square root approximation works well for large numbers, but leaves out some factors that are relevant for small numbers.

You're right that AES-128 is fine. Normally the birthday paradox only applies to cryptographic hashes.

The only way it would apply to symmetric keys is if you have a server that stores 2^64 encrypted messages, and can somehow find out which messages used the same symmetric key (normally not possible unless they also have the same IV and plaintext), and can somehow coerce the user who uploaded message #1 to decrypt message #2 for you (or vice versa). Obviously that isn't realistic.

> The chances of generating two GUIDs that are the same is astronomically small.

> The odds are 1 in 2^122 — that’s approximately 1 in 5,000,000,000,000,000,000,000,000,000,000,000,00.

This is true if you only generate two GUIDs, but if you generate very many GUIDs, the chance of generating two identical ones between any of them increases. E.g. if you generate 2^61 GUIDs, you have about a 1 in 2 chance of a collision, due to the birthday paradox.

2^61 is still a very large number of course, but much more feasible to reach than 2^122 when doing a collision attack. This is the reason that cryptographic hashes are typically 256 bits or more (to make the cost of collision attacks >= 2^128).

I may be missing something about how the PHP compiler/interpreter works, but I don't quite understand why this is apparently feasible to implement:

    class BlogPostRepository extends BaseRepository<BlogPost> { ... }
    $repo = new BlogPostRepository();

but the following would be very hard:

    $repo = new Repository<BlogPost>();

They write that the latter would need runtime support, instead of only compile time support. But why couldn't the latter be (compile time) syntactic sugar for the former, so to speak?

(As long as you don't allow the generic parameter to be dynamic / unknown at compile time, of course.)

Fair enough, I'm willing to believe it's doing evil things to hosts on the platform, indeed.

But FWIW, the EU is at least making an effort to regulate the company: https://nltimes.nl/2024/09/19/eu-court-says-bookingcom-wrong... (which claims that Booking can no longer prevent hosts in the EU from offering lower prices elsewhere).

I think there is some cultural difference between the US and Europe where in the US it's seen as somewhat OK to hold the customer service agents as personally responsible for the failings of the company, and treat them accordingly. Customer service agents in Europe dealing with Americans may feel the need to point out that they're not personally responsible for fear of said treatment. That (hopefully) doesn't mean that they won't try to help you, just that they hope you won't be angry at them personally.

It may sometimes be useful to verbalize this explicitly by saying "I know you're not responsible for this, but can you please do XYZ to solve the issue", and if it's a reasonable request I assume they'd be happy to comply. Depending on the country and culture, you may also need to be slightly more direct in asking (nicely!) for what you want, rather than hoping that the customer service rep will "make it right" by guessing what you want. You may perceive that as bad service but I think it's mainly about differing communication styles.

Apparently Priceline.com Inc. took over Booking.com (founded in the Netherlands) for € 110 million, and then changed its name to Booking Holdings to reflect the fact that Booking.com was much bigger than Priceline.com. Indeed a great example of "American innovation" :)

How so? At least Booking.com shows me the total price for an accommodation up front, without any additional fees or surprises coming up later in the booking process.

The same cannot be said for AirBnB: if I go to the home page right now it lists a bunch of bookings for e.g. "€ 80 for 2 nights", while when I click through the total price is €160. So apparently what they meant is "€80 per night". I'd call that much more of a dark pattern than anything I've seen Booking do.

It's interesting to claim that tourism in Europe won't be "durable" at a moment when tourism in the US is sharply declining..

Anyway, Booking.com is a European company and has many more customers than AirBnB.

> I arrived in Lyon recently and figured, hey, this is Europe, why not try the European app again, and used Bolt.

A bit off topic but IMHO your first thought should instead be: "hey, this is Europe, why not try the train?"

In Lyon, the train from the airport to the city takes half an hour, same as a car. My guess is that you'll have a vastly better experience than taking the train in North America, and also a better experience than at least the OP had when taking a Bolt.

I, as well, had degraded performance due to the temperature in Amsterdam today :)

Can't complain compared to folks in Spain or Italy, though.. But hopefully they're better prepared than we are.

Is it easy/cheap to get a stable IP address? I would worry that if I just get any cheap VPS host, they might switch the IP address at any point, but I'm not sure how true that actually is.

> But you would also not be reachable if the killswitch is active ;)

I would be, because I asked for a killswitch for the microphone and cameras, not a killswitch for connectivity like the original comment.

If I get a call while the killswitch is active, I can stop the sensitive conversation, turn on the microphone, and answer the call.

I don't think it's easy to not carry a phone, nowadays. Let's say I'm meeting up with someone: I'll need to use navigation, potentially message them if I'm running late, and so on.

Then once I'm there, what do I do with the phone? Ask to put it in a separate room and hope that the microphone isn't powerful enough to pick up our conversation?

I could turn it off entirely, but what if someone needs to call me for an emergency?

For me, as a user, the easiest solution would be to have a killswitch. I understand that building it would be more work, of course :)

I'd be happiest if they'd provide a physical switch for the microphone and cameras. That way, you could have a private conversation and be sure you're not being recorded.

Turning off connectivity doesn't help as much to guarantee your privacy as the phone could theoretically be recording and then upload the recording later, when you turn it back on (if it was thoroughly compromised, which admittedly seems unlikely, but nevertheless it would be nice to have some guarantee that it's impossible).

Yes, I understand and never said I disagree with that :) I'm just trying to provide some nuance and background about the specific issue discussed in this submission, as IMHO I think it's more interesting than making the same high-level points about OpenPGP over and over in every thread related to it (no offense meant, of course).

I would usually tend to agree with that, I was mainly just responding to the specific claim that OpenPGP doesn't have a definition of a well-formed packet sequence, which is false.

Also, as a maintainer of OpenPGP.js, I'd say that while the complexity of OpenPGP certainly didn't help, quite a lot of things needed to go wrong to create this vulnerability:

- The message grammar validation was incomplete, as mentioned

- The streaming decryption/validation code affected how the packet sequence was processed

- A later optimization when not streaming affected it further in a way that caused an inconsistency in which packets were being read when

- Finally, the architecture of the code made it possible to return different data than what was verified, which should not have been possible (and we'll address this as well in a future refactor)

All in all, I would place more of the "blame" on OpenPGP.js rather than OpenPGP. That being said, I don't think placing blame is the most important here; both OpenPGP.js and OpenPGP should and will learn from this.

FWIW, OpenPGP does have a definition of a well-formed packet sequence, e.g. for messages here: https://www.rfc-editor.org/rfc/rfc9580.html#name-openpgp-mes...

The packet sequence used by this vulnerability was not a valid OpenPGP message, as pointed out by the blog post (under the header "An invalid packet list").

Part of the issue in OpenPGP.js was that it didn't fully validate the message packet grammar, which has now been fixed: https://github.com/openpgpjs/openpgpjs/pull/1853

Edge no longer has its own engine, it's based on Chromium now. When it did, it also wouldn't qualify for STF funding because it wasn't open source.

But yes, a browser engine is potentially an embeddable library, so an open source one might qualify :)

Depending on how you define "global", https://www.sovereign.tech/programs/fund might qualify:

> With the Sovereign Tech Fund, we invest globally in the open software components that underpin Germany's and Europe's competitiveness and ability to innovate.

Not globally funded, but does invest globally.

However, they say:

> The Sovereign Tech Fund invests in open digital base technologies that are vital to the development of other software or enable digital networking. We invest in projects that benefit and strengthen the open source ecosystem. Examples include libraries for programming languages, package managers, open implementations of communication protocols, administration tools for developers, digital encryption technologies, and more. (...) We are currently not looking for user-facing applications, such as messaging apps or file storage services. If this changes, we will announce it here.

So, a browser wouldn't qualify, but an HTTP(S) library does, and perhaps even a browser engine would..?

Possibly https://github.com/freedomofpress/webcat? (I also made one, a long time ago: https://github.com/twiss/hcs-checker-firefox.)

There is also an effort to build this into browsers directly, which we (Proton) are involved with:

https://github.com/twiss/source-code-transparency (old initial proposal)

https://github.com/beurdouche/explainers/blob/main/waict-exp... (more recent proposal)

https://github.com/beurdouche/w3c-waict/blob/main/waict.bs (very early draft specification)