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-...
Will it? My level of doubt is high. There is very little recourse if the company decides to cease operations, which I think they will in the near future.
I think they could easily argue successfully that post-sale software updates were always contingent on continuing operation of the company.
After two years your battery will be almost unusable so genuinely it doesn't matter.
My only issue with oneplus phones, and I owned several of them already, is that they are running incredibly hot on normal usage, and battery capacity detoriates quickly over time.
They do have a great sleek UI and great hardware, not to mention fantastic supercharging capabilities which is a life saver sometimes, but all under the big cost.
Hmm my OnePlus 12 is 26 months old and battery is still phenomenal. I charge it to 80% and easily get a day of use, plugging in each night at 30-40%. I have not experienced it running hot yet.
I did not have battery issues with my OnePlus 7 Pro or OnePlus 9 Pro either. The 7 Pro gave me 3 days of battery! (I upgraded for camera improvements and faster screen refresh rate.)
My last one was 10 pro and battery is essentially dead after 2.5 years of usage. Can't make half of a day, literally unusable, and I'm not a big phone user. Case is made of some really good material, which feels very premium, but runs son fckn hot that you can't hold it in your hands anymore, this is especially true during hot summers, and it got only worse with the last major OS update. This is a heat dissipation issue caused by the materials used, large battery, and hi performance CPU cores so I don't think my case was any special than the others.
I see that the OnePlus 15 follows the same route, and although it has good reviews, and they claim they solved the battery heat dissipation and detoriation issues with some new kind of cells, it seems that it still runs hot according to some reviews I've seen on the yt.
Before that I had OnePlus 7 and more budget friendly Nord, and they were much better than 10 Pro, although 7 shared similar type of issues as 10 Pro. Nord is a bit different because case is not premium, and the battery is not so large, and the CPU is not premium nor the supercharging as well. However, it doesn't run hot and battery after few years of usage is still able to give you a full day without the problem.
I'm pretty convinced that all their flagships with hi performance CPUs, premium case, large battery, and fast charging suffer from the same issues.
Maybe mixed CPU core architecture is an answer to that issue, which might suggest why is so prevailing in other phone manufacturers but I have not dig that deep into the topic
Oneplus 15 uses a Si/C battery like other higher end Chinese phones currently. It doesn't get hot during normal operation (I don't play games on it) and since I don't use fast charging, for now it looks like it will work for a long time. Still get easily 2 days on a 80% charge.
I am not an idiot, I am not keeping my phone on direct sunlight neither do I run on "very high brightness". The phone runs hot on normal circumstances, and in summer when the temperatures are getting higher it becomes unbearable. I hope you understand now.
I've misread that you're having consistent problems across different models, sorry.
If it's just 10 Pro, then google says Qualcomm was having bad years (I've heard about Snapdragon 888 fiasco, but apparently it extended to 8 Gen 1 in OP10)
I had a similar issue with OnePlus 7 but not at this scale. It lasted me for 3, 3.5 years. I think this is becoming a problem more increasingly because of a beefier and beefier hardware that is put into these phones, and the heat dissipation problem hence becomes larger and larger problem which doesn't get automagically solved. I think that the best bet today is to take one with "subpar" CPU and larger battery and not so crazy supercharging capabilities
Interesting -- I thought OnePlus batteries were supposed to wear down LESS than other phones specifically because of their "High amp" charging technique versus "High voltage". After some quick research it seems this is mostly due to the heat generated during charging happens in the charger brick instead of the phone, keeping the heat away from the battery. But I suppose in real world situations it may not have a huge effect.
I was figthing a bit recently to make my 9210 Communicator charge again after well over 20 years in the drawer. But it eventually worked. The first phone with a color screen and a keyboard!
> After two years your battery will be almost unusable
After two years increasingly complex web apps will have made your hardware obsolete. Batteries can be swapped, bad web development at scale cannot be fixed.
Please see my other comment wrt Nord. What I am talking about is that flagship phones from OnePlus are suffering from the issues I described. I can't say every one of each suffers since my N=1 but the ones with the same characteristics and features I described above I am pretty sure that they do. There's a fundamental design flaw or we may call it a tradeoff.
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.
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.
That's the difficulty with the Light/Medium/Heavy Duty categories. It doesn't tell you a huge amount about what the vehicle is being used for but most of them heavy duty mean commercial or utility. There are a handful of popular models that tip into the Heavy duty class and those are usually 3/4 ton pickups. Not sure how popular those are in NYC though.
> 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. ;-)
