> 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.
> 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 have seen in my life two guid collisions already.
and i'm not that old.
One of them was genuine - generated by different systems, and it was caught when loading data from one to another - object had same ID, but different underlying type.
Other one was due to 'error' - two systems(by different companies, supporting the same data exchange standard) used magic hardcoded guid that turned out to be the same.
Both of those systems have full audit trail - each change created new row in database and IDs were formatted as {NAMESPACE}.{GUID}.{TIMESTAMP}. Mutation of an object created new entry with different {TIMESTAMP} part. Namescapes are mandated by standard, so different systems can have the same namespace value.
There are either bugs in the system or the GUID isn’t random. The first case you mention is probably both TBH; the second case is probably due to non-randomness (generating via namespace/timestamp leads to collisions when two objects are generated simultaneously).
The birthday paradox simplified : if you generate n bits of random data, you can at most generate n/2 bits of random numbers before clashes start to occur. That's square root of number's range.
So if you need 1000 random numbers, generate from 1 to 1 million.
You can also look at the expected number of collisions instead, which is approximately the number of random numbers squared, divided by the size of the space of random numbers.
Then you can choose how many collisions to accept on average. (If the answer is zero, then it makes more sense to look at the probability of one or more collisions.)
I always assumed that intuitively... I think the number is 20 people for the birthday paradox. 20 x 20 = 400, and there are ~365 days in a year. Is that how that works?
To actually find a collision in 128b cryptographic hash function it would take closer to 2^65 hashes. Back of the envelope calculations suggest that with Pollard's rho it would cost a few million dollars of CPU time at Hetzner's super-low prices. Not nearly mere mortals budget, but not that far off I guess.
That's great analysis. As you call out in the post, the 2^64 value is used to attack SHA256-128 (SHA256 truncated to 128 bits). NIST recommends at least SHA-224, which makes sense given your conclusions.
Depends on what “isn’t even that large means”. A modern 6ghz machine would probably need 12 years of 24/7 operation to count that high. To me that seems like a lot.
Well UUID generation isn’t going to be quite as SIMDable as counting so the analogy breaks down there partially because of that. And += 1 isn’t a very SIMDable operation? Unless I guess you create a mask of +1, +2, +3, +4 and add that to your base number to generate those offsets (which only works with avx512 - avx2 can only do 2 increments since these are 64bit integers)
Then your 32 HT threads aren’t really going to give you full access to the underlying SIMD registers which are going to be per core which is where I assume you realized the 2x difference might show up?
And to do += 1 multithreaded you have to partition the range or you won’t get any speed up - if you don’t amortize the cost of atomic synchronization across threads you’re going to be going slower than a non-SIMD increment.
Yeah, but a nation state server farm can probably cut that down to minutes because their budget can buy a lot of processors. You only need a few hundred to really shrink it down to manageable numbers. And it turns out that nation starts aren't the only ones that have this budget
It's trivial to force a collision. Here's the same UUID twice:
6e197264-d14b-44df-af98-39aac5681791
6e197264-d14b-44df-af98-39aac5681791
Typically, you don't care about UUIDs that aren't in your system and you generate those yourself to avoid maliciously generated collisions. Your system can't handle 2^61 IDs. It doesn't have the processing power, storage, or bandwidth for that to happen. Not to mention traditional rate limiting.
>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'm not sure. 6ghz is around 2^61 CPU cycles in 12 years. I.E. basic CPU instructions; counting, not computing a cryptographic hash. Otherwise, where is the cluster that's bruteforcing ~122 bit cryptographic hash collisions in minutes?
For what it’s worth generating a random UUID for the purposes of collision isn’t generally much more complicated than a few arithmetic instructions which is why I used counting as an example. And as the other poster mentioned generating a UUID collision isn’t a security problem since the UUID tends to be generated within your infrastructure where you can’t really go full blast at generating UUIDs for all sorts of reasons anyway.
For cryptographic applications it is really small because the previous poster is correct that 2^64 is very small for that purpose - a small supercomputing cluster or two could decrypt such a cipher in a reasonable amount of time, which is why symmetric keys are all 256 bits and up to guarantee there’s no way to attack them.
I don't think that's quite right. A 128-bit UUIDv4 having a 50% chance of having any collision after 2^61 generations is very different from finding a specific 128-bit symmetric key. The best cryptanalysis of AES-128 is 2^126; nowhere near 2^64. Which is why standards bodies like NIST still recommend AES-128 as a baseline.
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.
2^61 guids is... 36 exabytes, if my napkin math is correct. when storing them in binary format(16 bytes each) if doing the javascript thing and storing them as strings... (shudders) I don't even want to think about it.
Anyhow that was my first thought when you mentioned 2^61 guids, where are you even going to put them? second thought, I don't think enumerating 2^61 guids is trivial, in fact, I suspect it would take longer than anyone would be willing to spend, and if you are not storing them why are you generating them?
And what even is a guid collision attack? it is not like they are a hash, and since they tend to be public identifiers it turns out despite their stated use to prevent collisions, you can't really use guids generated by others(if they wanted collisions they would straight up just copy yours) so you end up regenerating them anyway.
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.)
The former merely exposes a `BlogPostRepository` class. The latter requires some mechanism for creating a generic object of concrete type, which is a lot bigger change to the implementation. Does each parametrized generic type have its own implementation? Or does each object have sufficient RTTI to dynamically dispatch? And what are the implications for module API data structures? Etc. In other words, this limitation avoids tremendously disruptive implementation impacts. Not pretty, but we're talking PHP here anyway. ;-)
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.
> It's interesting to claim that tourism in Europe won't be "durable" at a moment when tourism in the US is sharply declining..
Sorry to shatter your illusions, but for April 2025 (most recent month with final data) <https://view.officeapps.live.com/op/view.aspx?src=https%3A%2...>, Canadian visits are down 20% yoy but overall worldwide visits to US are up 1.3% yoy, including 17% yoy rise in Mexican visitors.
I don't understand what you are trying to claim.
1. Booking.com is owned by Booking Holdings which is an American parent company.
2. US GDP growth has been massively outperforming the EU since 2008.
I am saying tourism is not something governments should want to heavily optimize an economy for. No amount of taking money from people on vacation will translate into building a more competitive or innovative economy.
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.
Bookings.com runs some incredibly evil tactics. Generally they take about 20% of the booking fees. But they will do things like delist you if you have lower prices anywhere else, and then undercut your prices on their website.
My parents ran a small motel - the only hotel for miles around. But on top of the fees, if they weren't paying for additional promotions Booking would find unrelated distant hotels even when searching in the area. People would sometimes mistakenly book for a motel states away.
> 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.
In most major European cities I have been in the airport to train connection is pretty subpar unless traveling light.
There is typically no integration of the airport baggage handling with the train baggage handling. So you need to move everything with carts that you can't take on the train.
An international trip to Europe for a longer duration is also a significant trip and not something you want to "one bag". Add in jet lag, multiple young kids, car seats, stroller etc. and it quickly becomes easy to see why the train is cumbersome for the initial airport to lodging connection.
I assume young kids, car seats, etc. change the equation. As an adult doing basically urban travel, a few weeks with carryon is perfectly doable in my experience,
Depending on where you are going, ridesharing provides much better point to point service. Also, if you are not familiar with a city or it's language, sometimes trying to understand the public transit on your first day can be a nightmare.
I love taking public transit, but also, after a really long flight I can understand not wanting to think really hard about getting to the hotel.
Apple Maps, Google Maps, and I’m sure anything else under the sun will tell you specifically which train to take, in which direction. Usually, also with platform information, and in some cases even pricing/ticketing information.
Yes, traveling is a skill. It gets easier (and more comfortable) the more you practice it.
I have two people and four items of luggage plus a personal bag each. City trains are poor for this and subways are worse, but I am here for two weeks - I do need clean clothes.
In general, a lot of luggage doesn't work well on public transit on any continent. I've generally moved towards packing lighter but it isn't always possible. For two weeks in cities I can mostly do carryon. If I'm hiking/camping, yes, I may need more.
My wife does not pack light either. She loves giant suitcases. It is always an argument that I rather bring four carry on size suitcases so I can manhandle them up the many stairs in Europe. Instead of two jumbo suitcases.
It is her chance to dress up. She packs ten different outfits…
I can handle the FrecciaRossa and SNAV with all that the luggage. Can’t do it on local bus or train. I was pleasantly surprised by Rome’s buses. Now I tap my credit card. No more having to go to a local shop to buy a ticket or pay by cash.
However, it’s not that much. Two weeks in one carryon is tight for me; she has trouble doing a weekend in one, and that doesn’t include hanging clothes.
I’ve done it with one luggage and one small backpack each, with no discomfort. If it’s a single warm-ish climate it can even be done with one backpack.
I've done that too, but it is indeed harder in winter.
It does mean you have to plan for wearing everything you bring, no extra fancy clothes you may or may not wear. But it doesn't require other sacrifices.
> two people and four items of luggage plus a personal bag each
Well, there's you problem. I have traveled the world, including many trips of 6 weeks or more, with only a single. carry-on. Laundromats exist everywhere.
Snark aside, a bit of planning and organization w.r.t. packing pays off handsomely in terms of flexibility when traveling.
Spontaneous weekend trip to a remote island when carrying only a backpack - sure. Add two heavy suitcases, and it becomes an impossibility.
Please don't tell other people how they should live.
Personally I love travelling light (<10kg carry-on pack for 2 months last year to South America) but it isn't for everyone.
> Laundromats exist everywhere.
Only if you value your time at nearly $0. They are incredibly annoying when travelling - too often a 10 or 15 minute walk each way to one. Great for backpacking, but a complete waste of time if you only have a limited amount of time for your holiday.
Having just got back from a 8 week European vacation, with a wife+kid+me.
There's also the small issue of it being was 95F degrees outside at 75% humidity (southern France). This means 1 outfit isn't lasting more than a day (sometimes only 1/2 a day) before becoming unbearably stinky. x3 this means laundry needs to be done every other day or packing a ton of stuff.
True, but I think we can be charitable and forgive Americans for defaulting to "apps" versus actual infrastructure, given the poor state of public transportation in the US and the lack of exposure to quality publicly funded infrastructure.
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.
Easy yes. Even VPS providers need to maintain the IP, since your DNS typically points to that IP. You can also typically move the IP to another machine from the same provider.
But as a resut, VPS often have a different price for public IPs compared to private IPs. For instance, it costs €0.004/h per IP at Scaleway.
I've used dozens of VPS providers in the past, albeit 'low end' in this instance- they constantly change IP addresses because they're renting them, buying them, etc.
For IPv4 definitely a problem.
I maybe used around 100 VPS hosts, less well known ones beyong DO etc. I'd get a dozen IP change notices a year.
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).
Such a device, sufficiently deshittified, might win some contracts in the sasec (safety and security) biz. But let's be honest, the Fairphone, strictly from a security standpoint, is more aimed at the performativity crowd. Heck, most people already seem to lack the imagination for when and why killswitches and the like might be a really good idea. Kind of like with mSD card slots, audio jacks, etc.
Wireless-only, data-harvesting slabs are good enough for ME, so they oughta be good enough FOR EVERYONE!
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 :)
Yes, that's what I had to do for meetings that the organizer thought were important enough. Also, in very sensitive areas special rooms with anti-eavesdropping gear are common [1].
> I could turn it off entirely, but what if someone needs to call me for an emergency?
But you would also not be reachable if the killswitch is active ;)
Don't get me wrong, I think a killswitch can make a lot of sense for highly sensitive areas (R&D, politics, military, ...), but I don't think Fairphone 6 are the devices that target this demographic and thus should not include one. Furthermore, current "offline" measure seem to mitigate the problem okay enough to not need such a killswitch - else we would already have phones with such features. And lastly, killswitches can only mitigate parts of the features modern spyware [2] implements and does not protect from simple human-based errors like the United States government group chat leaks [3].
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