wow, lots of critical bugs coming out of Cupertino lately. Mail security bug and now this.
That's quite a list you have there. Two.
And yesterday your list of examples would have had one on it.
wow, lots of critical bugs coming out of Cupertino lately. Mail security bug and now this.
Nothing new really. iMessage has had a long history of these vulnerabilities. If you want security and reliability you use something else for messaging, mail, etc.
It probably has to do with the utf-string library and thus, not direclty the fault of the iMessage programmers.How hard can it possibly be to just have something like:
Code:try { renderText(); } catch (Exception e) { renderUnprintable(); reportToApple(e); }
I know, that's Java and Apple would actually use Swift, but still, how hard can it possibly be to just not let the exception through?
If you get them from people you know, it's a great way to find out who to block permanently.Great. Looking forward to receive texts like these again!
You know there are trillions of character glyphs and thus the combination is in a stratospheric number.Right - this seems pretty easy to unit-test. Just use Chaos Monkey or something and have it throw every possible combination of characters at it.
Please no. Unicode fixed an enormous number of communication problems for computers. Going back to what we had before would be roughy akin to taking medicine back to before we had antibiotics and anesthesia. Plus, English only covers the majority of the US, part of Canada, England, and India (and a few other spots). There are a lot of other countries we'd like to converse with.Isn't it time to scrap all these crazya$$ fonts, which pose a national security risk, and go back to just plain normal English plus maybe dingwingbats?
You know there are trillions of character glyphs and thus the combination is in a stratospheric number.
And yet other people seem to be able to find the fun ones... it would be nice if Apple deployed the resources to find them first.You know there are trillions of character glyphs and thus the combination is in a stratospheric number.
*iMessages only. Normal texts still come through normally.You can pretty much already do this. You can have unknown numbers be sent to voicemail, and unknown texts be filtered into a separate list. You'll get no notifications for either these.
With at least 40 million lines of in windows (Xp) and lots in iOS it is rocket science. If it were so easy windows being in existence for 30 years should be bug free.If Apple has to resort to bombarding their input with every combination and permutation of every glyph in existence in order to ascertain there are no issues, then they have got everything backwards. It's better to develop a good systematic understanding of their own code and keep userspace strings from interfering with the kernel code (or whatever). Some computer languages make this a fairly easy task - they keep (and treat) strings as strings and do a great job compartmentalizing. It ain't rocket science.
How hard can it possibly be to just have something like:
Code:try { renderText(); } catch (Exception e) { renderUnprintable(); reportToApple(e); }
I know, that's Java and Apple would actually use Swift, but still, how hard can it possibly be to just not let the exception through?
How hard is it to have a test for every UTF character? Seriously, verify("A"), verify("B")...It probably has to do with the utf-string library and thus, not direclty the fault of the iMessage programmers.
Well, but it’s on your testing device, obviously not on your primary phone, so no big deal.Oh damn. I installed 13.4.5 beta 2 earlier to mitigate the E-mail vulnerability, and today a new bug that's fixed in that update pops up.
Best choice ever to install an otherwise meaningless beta!
Maybe they’re malicious by natureReceived FROM a malicious person. Not BY.
Nothing new really. iMessage has had a long history of these vulnerabilities. If you want security and reliability you use something else for messaging, mail, etc.
How hard is it to have a test for every UTF character? Seriously, verify("A"), verify("B")...