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

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

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

Only Safari supports it for now, it seems.

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

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

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

    $repo = new Repository();

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

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

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.

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.

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

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.

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

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.

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 :)

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