91–100 of 122 posts
This isn't the first time a weird sequence of Unicode characters has caused the text renderer to crash and create problems for iOS users. This is why we shouldn't be writing new code in C.
More like "this is why we should use LLVM's libFuzzer or similar". Apple is just not doing basic code hygiene stuff here.
Earlier quoted context omitted.
I guess it depends on your definition of "widely spoken." According to Wikipedia, the number of people speaking Telugu is 0.97% of the world. It's not even a statistical margin of error. Still, how hard can it be to have a machine step through all of the possible combinations of every iOS-supported character set and jam them into iMessage to see if they're failsafe? [1]: https://en.wikipedia.org/wiki/Telugu_language
1%? Are you kidding? That's over 70 million. It's on the order of population of Germany, and 10 times more, than Swedes.
I wonder how many more of this flops will it take for some security experts to stop recommending iPhone over Android...
90% of android phones not having any recent updates - big deal. [0]
[0] https://www.sammobile.com/news/samsung-stops-galaxy-s8-andro...
This isn't the first time a weird sequence of Unicode characters has caused the text renderer to crash and create problems for iOS users. This is why we shouldn't be writing new code in C.
>This is why we shouldn't be writing new code in C. Depends on your priorities. I'd take occasional bugs over jitter, latency, CPU inefficiency, and excess memory usage. And all that in practical terms means C is very environmentally friendly.
Here's a link to the character if someone wants to test it themselves https://pastebin.com/9Tr8ytTr
also crashed firefox on mac and chrome somebody should just paste them here in the comments seeing the % of people here who run macos
What Apple, and Microsoft before them, are discovering is the tools and processes we use to create software simply doesn't scale. We're simply reaching the limits of what these giant software teams are able to produce and keep running. We can discuss solutions, but currently not everybody even agrees we have a problem. That's the first step we need to take.
We've started on this path with Apps, we just need to lock it in with an open source OS that is simply a userdata securing app store.
I wonder how many more of this flops will it take for some security experts to stop recommending iPhone over Android...
weird unicode text can crash your imessages - sucks. 90% of android phones not having any recent updates - big deal. [0] [0] https://www.sammobile.com/news/samsung-stops-galaxy-s8-andro...
And it's interesting that you bring Samsung that for 3 years issued patches every single month for my old Note 4. You may not get latest and greatest Android version immediately (missing the essential "hamburger emoji fix") but you'll still get security updates.
Does anybody know how to get out of the respring/reboot loop without reinstalling everything in DFU?
(Very bad joke on my part)
EDIT: apparently he did go into recovery but didn't lose his files.
He says you have to go in DFU, press shift and click on update then select the file for the 11.3 beta upgrade.
Earlier quoted context omitted.
>This is why we shouldn't be writing new code in C. Depends on your priorities. I'd take occasional bugs over jitter, latency, CPU inefficiency, and excess memory usage. And all that in practical terms means C is very environmentally friendly.
Choose Rust. It has zero-overhead memory and data race safety.
I've never done any fuzzing personally, but wouldn't this be discoverable internally during testing? I would think that they would attempt sending all possible characters, especially because they've had issues with this in the past.
Well of course they could have done that. To be honest, though, if someone on my team suggested we implement an automated test that tries sending every Unicode character (and it would be applied to every interface of every app and API, right?) I would have objected that this was an over-complicated, over-engineered solution that will probably be too slow. I'd argue that a set of test data selected to cover a range of…
IMO fast probabilistic total coverage test is better than no test or partial coverage.