A Text Message Can Crash An iPhone and Force It To Reboot 248
DavidGilbert99 writes with news that a bug in iOS has made it so anyone can crash an iPhone by simply sending it a text message containing certain characters. "When the text message is displayed by a banner alert or notification on the lockscreen, the system attempts to abbreviate the text with an ellipsis. If the ellipsis is placed in the middle of a set of non-Latin script characters, including Arabic, Marathi and Chinese, it causes the system to crash and the phone to reboot." The text string is specific enough that it's unlikely to happen by accident, and users can disable text notification banners to protect themselves from being affected. However, if a user receives the crash-inducing text, they won't be able to access the Messages app without causing another crash. A similar bug crashed applications in OS X a few years ago.
My friend knows about this... (Score:5, Funny)
https://xkcd.com/327/ [xkcd.com]
I still laugh at this... am I an idiot? Don't answer that.
Re: (Score:3)
One of the best xkcd's of all time
Re: (Score:2)
Funny as hell.
Re: (Score:2)
Re: (Score:2)
You sound upset, maybe you need to get in your BMW and go visit your supermodel girlfriend for some comfort.
Dude, don't tell him THAT! (quickly putting clothes on and scramming out the back door...)
Apple Watch (Score:3, Funny)
Getting notifications on an Apple Watch also protects the iPhone from the bug.
They have to push sales of the iWatch some ways...
Nokia phones did this years ago. (Score:3)
Years ago, I had a number of Nokia flip phones. I also converted emails to text messages and sent them to the phone (actually, probably MMS, not SMS), so that I could read my emails on a dumb phone.
However, every now and again, I would receive a "text of death". The phone would receive a text message, crash, reboot, attempt to download text messages again, crash .... etc.. It continued to do this until the network would decide to give up attempting to send that MMS message.
I had several phones of the same model and they all did this.
Re:Nokia phones did this years ago. (Score:4, Funny)
See everyone? Apple doesn't invent anything! They just do it with more polish.
Re:Nokia phones did this years ago. (Score:4, Interesting)
I've got a better story than that. Back in the mid-80's, when I was working at IBM, we did almost all of our programming in REXX and APL2 using dumb terminals.
One of the features of the system was the ability to send a message to another user that would appear directly on his or her screen like a text message.
By accident, one of the guys in my group discovered that by sending a certain string of characters to another user, he could force the receipt's terminal to automatically log off. Predictably, this led to a campaign of various people sending the "message of death" to each other, hearing the recipient yell and curse, and then quickly closing any open file before the victim fired back with a message of his own. This went on for about two weeks before we all got tired of it.
And of course I could also talk about the REXX worm that shut down the entire IBM internal email system for more than a day, but that is another story. :-)
Everything old is new again.
Re: (Score:2)
You could do that on Unix System III with ADM-12 terminals as well.
Re: (Score:2)
Re: (Score:2)
I came here to comment on this. There are services and botnets that can send millions of simultaneous texts. I once read a blackhat idea of rebooting millions of phones over and over or all at once to see if it would crash the next layers of the networks. Maybe the towers couldn't handle it and would go down. And then ...
Message coming in from the ghost of Steve Jobs (Score:2, Funny)
"You're reading it the wrong way."
Did they already fix this? (Score:2)
Did Apple already fix this? I immediately tried to crash every phone of every coworker who has an iPhone within earshot of me and it didn't work. Much to my disappointment. I'm now having to save face by harassing them with Pictures of Steve Job's license plateless car parked in multiple handicapped spots.
Re:Did they already fix this? (Score:5, Funny)
I immediately tried to crash every phone of every coworker who has an iPhone within earshot of me and it didn't work.
I too enjoy getting fired over stupid shit. Do you have any other suggestions I might try?
Re: (Score:2)
Re: (Score:2)
Were you using SMS or iMessage? This is probably fixable in iMessage -- they get routed through Apple's servers and could probably be sanitized so that the offending characters can be byte-aligned to avoid the crash -- but SMSes go directly through the carriers and would require an OS update.
Cool (Score:2)
laughing (Score:2)
The next time an Apple-head tells you that their walled garden is there to protect the user and improved their experience and make the device more dependable just laugh in their face.
Re:Lol (Score:5, Insightful)
it's a parsing bug, what difference would sanitizing user input make...
Re: (Score:2)
it's a parsing bug, what difference would sanitizing user input make...
Well if your parser can't handle something, it should sanitize input before parsing it. Eg if you use special characters internally to do something, make sure your user input doesn't have those characters in that order unless you want the user to be doing that thing.
Even if you just add something, eg "\ " if spaces do special things, and a user input "\" can be stored internally as "\\".
Re: (Score:3)
Eccch ... and suddenly I'm reminded of things where you need to escape the escape of the escaping of the escape so that it doesn't keel over.
And then it become "Yo, Dawg, I hear you like escape characters".
It can pretty quickly devolve into really annoying things, especially when something else wants to read it, or when humans have to. I've seen things with things which turned into ni
Re: Lol (Score:5, Informative)
It's not a special character that needs escaping. It's a character that needs multiple bytes to specify the code point. The parser just isn't handling the fact that you can't just crop a character mid code point - it's operating at the byte level when it should be operating at the code point level during a crop operation.
Re: (Score:3)
It's not a special character that needs escaping. It's a character that needs multiple bytes to specify the code point. The parser just isn't handling the fact that you can't just crop a character mid code point - it's operating at the byte level when it should be operating at the code point level during a crop operation.
Too bad I don't have mod points because you are absolutely correct! As more and more code points are defined, the number of bytes needed to represent characters increases. Their abbreviation mechanism should at least recognize surrogate pairs and combining characters.
Re: Lol (Score:4, Interesting)
And since some characters have different lengths, even counting characters might not be good enough. (Can't use max_bytes=80, nor max_chars=40.)
The message could be "displayed" in memory with the chosen font and size to calculate it's length, then truncate the string in character mode to fit within the limited area.
Re: (Score:3)
No, the problem is code that pretends that illegal UTF-8 sequences magically don't exist!
For some reason UTF-8 turns otherwise intelligent programmers into complete morons. Here is another example from Apple. Let me state some rules about how to deal with UTF-8:
1. Stop thinking about "characters"!!!! This is a byte stream. The ONLY reason to think about a "character" is because you are DRAWING it on a display designed for a human to read, and humans do think about "characters". All other software either doe
Re: (Score:2)
No, the problem is code that pretends that illegal UTF-8 sequences magically don't exist!
Where's the illegal UTF-8 sequence in the message? Is the actual octet sequence in the message different from what's in this Slashdot posting [slashdot.org] (once converted to a sequence of octets), which contains no invalid UTF-8 sequences (yes, I went through them all by hand)?
Re:Lol (Score:4, Insightful)
It wouldn't be a parsing bug if the parser sanitized its input.
Re: (Score:2)
Re: (Score:3)
Re: (Score:3)
And to sanitise the input what process would you need to perform on the input? is it called parsing? and would you need to sanitise the sanitisers parser...
Yes, you could do it with a simpler parser eg delete all non-latin characters from user input because the people who designed our parser were noobs. Or go on a case-by-case basis, this character is used internally for such and such, if user input has this character then put an escape character in front of it or whatever.
For example, a fun gag on a new Linux user is to create a file called " -rf" and ask them to delete it via a command line. If they naively type "rm -rf" then it gets parsed as an option for
Re: (Score:2)
Problem with this case is that people who don't speak languages that use latin characters are going to be pissed that they can't get texts in their language.
The real bigger problem is that Unicode is hard, and it's probably some weird unchecked buffer overflow or something stupid. What's strange is that when another text is sent, the problem case solves itself and the messaging app becomes usable again.
Re: (Score:2)
What's strange is that when another text is sent, the problem case solves itself and the messaging app becomes usable again.
It's not that weird. The IOS messaging app shows messages organized by sender with the most recent message summarized under each sender's name. If a message is being cropped incorrectly and causing the crash, then wh3n another message comes in from that sender, the new message will replace the problematic one in the summary.
Re: (Score:2)
Nice, fuck everyone who doesn't speak English, amirite?
Re: (Score:2)
It's the Slashdot way.
Re: (Score:2)
It wouldn't be a parsing bug if the parser sanitized its input.
And what exactly do you mean by 'sanitized its input' in this case? Since we're talking about truncating a string of non-latin character sets with variable-length values for the codepoints the problem is with the parser not correctly handling this and assuming fixed length codepoint values. Changing the input is most definitely the wrong way to handle a bug like this.
Re: (Score:2)
There's no law that says they can't pad the variable length input to fixed length
I'm not sure you quite understand the problem, it's not the input length, it is the encoding of each of the characters. So are you suggesting turning all single-byte encoded characters into multi-byte encoding of some arbitrary maximum length? If you can already identify the problem at this level then you would just do that in the parser that is truncating the string.
Re: (Score:2)
And it's nothing new that a "text" message can crash a phone. It can happen on many phones, and you can send OTA messages for configuration to really screw up the phone for someone.
Re:Lol (Score:5, Insightful)
Sanitize a language people use for actual communication? The text shouldn't have to change. This is a case of bad coding and nothing more.
Re: (Score:2)
Sanitize a language people use for actual communication?
Yeah, not so much [macrumors.com]. It's bad coding because of a lack of sanitizing.
Re:Lol (Score:4, Informative)
Just because it's unlikely with a real text string doesn't mean that any of the text is invalid for a message. The text string should still not need to be changed. The bug only affects notifications, and it's clear that the text can be displayed just fine in conversation view.
This is almost certainly due to splitting multibyte characters on sub-character boundaries. That's a design problem, not a sanitizing problem.
Re: (Score:2)
Just because it's unlikely with a real text string doesn't mean that any of the text is invalid for a message. The text string should still not need to be changed. The bug only affects notifications, and it's clear that the text can be displayed just fine in conversation view.
This is almost certainly due to splitting multibyte characters on sub-character boundaries.
Or mishandling combining characters; the screenshot geminidomino provided shows several combining characters, as indicated by the dotted-line circles in some of the glyphs (and I suspect some of the marks above the Arabic characters come from combining characters as well).
Re: (Score:2)
Re: (Score:2)
Yes, it is. Any input that will crash your library needs to be sanitized. You need to truncate the message on display, at the bad character. That doesn't mean you change the source message or render whatever folks use it to communicate unable to do that- you as the fucking programmer SANITIZE YOUR INPUT, because otherwise, you fuck the user.
Re: (Score:3)
Re: (Score:2)
No you don't. You are demonstrating the typical moronic attempts to deal with UTF-8.
Here is how you do it:
Go X bytes into the string. If that byte is a continuation byte, back up. Back up a maximum of 3 times. This will find a truncation point that will not introduce more errors into the string than are already there.
BUT BUT BUT I'm sure you are sputtering about how this won't give you exactly X "characters". NOBODY F**KING CARES!!!! If you want the string to "fit" you should be *measuring* it, not saying s
Re: (Score:2)
This only works for UTF-8, and theoretically fails with the older type of UTF-8 (when you could have up to 6 bytes, by spec).
So you probably will have to go through it character by character, not byte by byte, exactly as Brons said. If you go N bytes into the string, and the string was just a ton of kanji, then you might truncate a VERY short message indeed- if you go looking 40 bytes in, you could be looking at a 10 character string or something for no reason, when your display would happily fit 40.
Re: (Score:2)
You guys that are talking about sanitizing the input don't understand the bug. There is absolutely nothing wrong with the input. This is not injection of escape codes. It's valid text in a different language, and changing at at input would constitute a second defect. The problem is connected to the eliding algorithm.
And in fact the argument where in the code the problem lies is not that helpful anyway. The bigger problem is that there wasn't a test case for it.
Re: (Score:2)
The string doesn't just need funny characters in it, it needs them at a precise position (and apparently not just any character will break, so it needs to have a particular expansion in whatever they used to encode their unicode). A test case would have solved it, but it doesn't sound like a reasonable test case to expect.
And yes, if you call a library that does some buggy truncation, you need to guard it on input.
Re: (Score:2)
Yes, it is. Any input that will crash your library needs to be sanitized. You need to truncate the message on display, at the bad character.
Where has it ever been stated that the message, as sent to the phone, contains a bad character? Everything I've read indicates that the problem is that the code that's displaying the message is inserting an ellipsis in the middle of a perfectly valid character, making the resulting string invalid.
That's not un-sanitized input, it's bad output, from buggy code.
Re: (Score:2)
It's a bad character if the library you call will fuck it up. That's what makes it bad. Once you overwrite part of some multibyte character IT IS A BAD CHARACTER!!!
Re:I am amazed (Score:4, Informative)
Re: (Score:3, Interesting)
Generally, if a carefully-crafted input can cause your application to crash, a similarly-crafted data may be able to exploit the same bug and cause an execution of malicious code. If — as is usually the case — the crash is due to buffer overflow and I can stomp over your app's memory, I may be able to place my code in the right place and it wil
Re: (Score:2)
This is only true for certain classes of memory management defects. There are many different kinds of defects, and man
Re: (Score:2)
Correct. As a random example, a NULL pointer read - certainly the most common class of memory error I've seen, probably the most common by far in general - is almost never exploitable (for arbitrary code execution). You can use it to crash programs (denial of service) but usually not for anything else.
Re:I am amazed (Score:4, Informative)
I'd be willing to bet that the unicode library they were using was UTF-16 . Either that or they were handling unicode in a straight binary string with something homebrewed. Both are horribly dangerous - the latter for obvious reasons, but the former in particular because it makes it easy to code something that "just works" for 99,99% of cases, but those rare 0,01% side cases involving 32-bit unicode characters slip through testing and come back and bite you down the road. It's amazing how many apps have incorrect behavior with 4-byte unicode characters, on a wide range of platforms.
Both should be considered bad practice and programming languages evolved to standardize on UTF-8 for any string format that is to handle unicode. C++ for example needs to introduce something along the lines of "std::ustring" that makes unicode string ops "just work" with a UTF-8 backend, at the cost of some memory and performance vs. std::string, which should be seen as exclusively for ascii and binary string operations. std::wstring should be obsoleted.
Re: (Score:3)
Apple's NSString implementation is at least 15 years old. Sure it's been improved over the years, but it's not like Apple's a newcomer to parsing Unicode.
Bugs happen.
Re:I am amazed (Score:5, Interesting)
It's not that NSString itself is broken, it's that the fact that 99.99% of the time an NSString is one 16-bit code unit per glyph that apps using it rarely test the use case where it's two code units per glyph. So a person goes in and writes an app that inserts a new character at a particular byte offset and it works 99.99% of the time, but if it happens to get stuck in the middle of a multi-code-unit glyph, the program breaks.
The documentation is no help. First off, it lies:
As we all should know, that's simply not true. Unfortunately, a lot of people don't know better. Unicode is not a universal, uniform encoding scheme that is 16 bits per character. Even UTF-16 isn't that.
characterAtIndex returns a 16-bit integer. So obviously it has no way to actually represent wider unicode characters. The length method is not the number of characters on the screen, but the number of code units, which is different, but highly misleading to programmers. They're, again, the same thing 99.99% of the time, but those rare cases where they're not generally slip through testing. And this is why UTF-16 is such a hazardous encoding to use.
Yes, NSString is old. And that's part of the problem. It was made at a time where many thought that unicode was only going to be 16 bits. It hasn't aged well. And it's caused a lot of bugs over its time. And now I'd bet that it or something similar has created a brand new iPhone-equivalent of Winnuke.
Programmers really need two types of strings, and only two, for the lion's share of tasks. One, binary strings, where a char is always 8 bytes and operations can be optimized to heck and back. And two, unicode strings, where a char always represents a whole unicode character that you would display, and the count of characters represents the count of display characters and so forth. None of this "99.99% of the time it's one thing, but every so often it's another...". That's asking for bugs.
Re: (Score:2)
As far as I can see the new String type used by Swift does it right.
Although when using existing Cocoa APIs it's get bridged to NSString anyway, so we're not out of the woods yet.
Re: (Score:2)
Actually I think "Unicode strings" should be avoided completely.
They do not help at all in doing text manipulation, because Unicode code points are *not* "characters" or any other unit that users think about. This is due to combining characters and invisible characters such as bidi indicators. There is a prefix code unit that eats the next 2 letters and turns it into a country flag! It is a huge mess.
Far more important is they all lack the ability to store errors that are in a UTF-8 string in a lossless way
Re: (Score:2)
Pretty much all Unicode handling in framework libraries is UTF-16, and has been for quite a long time. Windows "wide" strings, Java String, .NET String, Qt QString, ICU UnicodeString, etc. Of course some libraries may support choosing between the two, and many newer libraries do opt for UTF-8. Serialized formats are also more likely to be UTF-8. However, UTF-16 is still far more common as the "in memory" representation.
Since multi-element characters are far less common in UTF-16 than in UTF-8, I can see h
Re: (Score:3)
Yep, they have been UTF-16 for a long time. And Unicode has been widely broken for a long time. It's not a coincidence.
Someone on StackExchange did some tests last year, adding in 4-byte unicode characters in common applications and seeing how they behaved. The results were really bad:
Re: (Score:2)
My recommendation is special interators on std::string. Something like this:
for (utf16_interator i = string.begin(); i != string.end(); ++i) {
int x = *i;
if (x < 0) error_byte_found();
else utf16_found(x);
}
There would also be interators for UTF-32 (probably what you were thinking of as "Unicode" but a lot of Microsoft programmers think "Unicode" means UTF-16). And iterat
Re: (Score:2)
Or as just "text" on non-broken compilers. Compilers that translate the input into UTF-16 as part of the parsing are broken however.
Re: (Score:3)
I think you hit the nail on the head when you observed "they never bothered testing."
As long as software vendors have zero liability for defects, we'll probably continue to see easy-to-catch and easy-to-exploit bugs in software. Even software out of large, mature dev groups that should really know better.
Re: (Score:2)
Now, that is a bit disingenuous. TFS says The text string is specific enough that it's unlikely to happen by accident.
You can test and test and test, and it's still not possible to say you have tested every conceivable combination of stuff.
This doesn't sound like an "easy-to-catch and easy-to-exploit bug", this sounds like something obscure and unlikely. And it can be a bear tracking down and identifying something like th
Re: (Score:2)
This isn't as difficult to find as you might think. You do not have to test millions or billions of random text strings.
Software security testing works by breaking inputs into categories, and assuming that if you test one or two items in the category, then the category is covered. Categories are derived from the software specifications.
Example categories: ...
1. 0-byte message
2. max-length message
3. max-length +1 message
4. message consisting of all NULL bytes
5. message with unicode characters
If ellipses ar
Re: (Score:2, Informative)
To clarify: the iPhone has been out for (almost) 8 years, and only now the offending string was found.
No testing provides 100% coverage, especially for the number of combinations of possible Unicode characters in a 160-character/byte message. Only a complete moron would blame this bug on lack of testing.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Let's not forget that Unicode is a standard that's constantly evolving - new glyphs are constantly added (there's already a new proposed set for Unicode 9 including glyphs for "selfie", "avocado" and others)
People keep arguing that /. doesn't support Unicode, when it really does - it just uses a narrow white
Re: (Score:2)
People keep arguing that /. doesn't support Unicode, when it really does - it just uses a narrow whitelist of characters. The reason for this is obvious if you think about it - to prevent situations like this from happening.
Heck, there might be strings out there that will crash any Unicode library implementation, just we haven't found them yet because the search space is huge.
Hmmm ... That tempts me to try a test using a couple of file names on this machine that are two of the names for a Mandarin-English dictionary: .html and Ptnghuà.html (and also Pu3Tong1Hua4.html for systems that can only accept ASCII ;-). Those names aren't in any sense obscure or tricky; they're strings you'd expect to see in online discussions of text handling in various languages. If you can't handle at least these trivial Chinese strings, you've failed pretty badly. Of course, they look findin
Re: (Score:2)
People keep arguing that /. doesn't support Unicode, when it really does - it just uses a narrow whitelist of characters. The reason for this is obvious if you think about it - to prevent situations like this from happening.
Heck, there might be strings out there that will crash any Unicode library implementation, just we haven't found them yet because the search space is huge.
Hmmm ... That tempts me to try a test using a couple of file names on this machine that are two of the names for a Mandarin-English dictionary: .html and Ptnghuà.html (and also Pu3Tong1Hua4.html for systems that can only accept ASCII ;-). Those names aren't in any sense obscure or tricky; they're strings you'd expect to see in online discussions of text handling in various languages. If you can't handle at least these trivial Chinese strings, you've failed pretty badly. Of course, they look findin this Comment: panel, and will likely survive the Preview button.
Let's see how /. handles them ...
Nope; the 3 Hanzi characters didn't show at all, and only the à showed correctly in the second name. But both everything looks correct in this second editing widget. This proves that /. hasn't damaged the actual text in the Preview. Let's see what happens when I try to post it ...
I see that the "Comment:" edit widget for this message does have the Hanzi and marked 'u' and 'o' characters missing. So the damage is done after you hit the Submit button. There's no excuse for this. None of those characters have any special meaning to the code, and text containing them can't do any damage to anything. If damage happens, it's the fault of the crappy software handling the text, not the fault of the creator of the text. The right thing to do is to correct the crappy software. Damaging
Re: (Score:2)
Yes, technically there is a way to execute phone specific code with specially crafted text messages.
"Click here to install a puppy screensaver!!!"
Re: (Score:2)
They probably tested with most of the unicode set. They probably didn't test with all of the unicode set at the exact message length (and in the correct position) needed to find this bug.
Re: (Score:2)
Yes, there are special types of SMS the carrier can use to send commands to your baseband chip.
Re: (Score:3)
We can't tell you. It requires Unicode characters that /. won't render.
Re: (Score:2)
hex code would be fine
Re: (Score:2)
Would it crash /. ? :)
Re: (Score:2)
The Guardian were probably too scared at the thought of an Apple lawsuit to publish the actual text.
Re: (Score:3, Informative)
https://www.reddit.com/r/apple/comments/37enow/about_the_latest_iphone_security_vulnerability/
We've come to a time that reddit posts are more infotmative then slashdot articles.
Re: (Score:2)
I found this:
and this:
Power
h
but neither did anything.
haha just notice slashdot won't display the unicode.
See here: https://zhovner.com/tmp/killwe... [zhovner.com]
and here: http://www.ibtimes.com/text-ca... [ibtimes.com]
Re: (Score:2)
In hex, the string is:
506f 7765 7220 d984 d98f d984 d98f d8b5 d991 d8a8 d98f d984 d98f d984 d8b5 d991 d8a8 d98f d8b1 d8b1 d98b 20e0 a5a3 20e0 a5a3 6820 e0a5 a320 e0a5 a320 e586 97
That's the string encoded as UTF-8, so it's more like
50 6f 77 65 72 20 d9 84 d9 8f d9 84 d9 8f d8 b5 d9 91 d8 a8 d9 8f d9 84 d9 8f d9 84 d8 b5 d9 91 d8 a8 d9 8f d8 b1 d8 b1 d9 8b 20 e0 a5 a3 20 e0 a5 a3 68 20 e0 a5 a3 20 e0 a5 a3 20 e5 86 97
If we turn that into a sequence of (21-bit) Unicode code points, it becomes
000050 00006f 000077 000065 000072 000020 000644 00064f 000644 00064f 000635 000651 000628 00064f 000644 00064f 000644 000635 000651 000628 00064f 000631 000631 00064b 000020 000963 000020 00096
Re: (Score:2)
That's the string encoded as UTF-8, so it's more like
50 6f 77 65 72 20 d9 84 d9 8f d9 84 d9 8f d8 b5 d9 91 d8 a8 d9 8f d9 84 d9 8f d9 84 d8 b5 d9 91 d8 a8 d9 8f d8 b1 d8 b1 d9 8b 20 e0 a5 a3 20 e0 a5 a3 68 20 e0 a5 a3 20 e0 a5 a3 20 e5 86 97
If we turn that into a sequence of (21-bit) Unicode code points, it becomes
000050 00006f 000077 000065 000072 000020 000644 00064f 000644 00064f 000635 000651 000628 00064f 000644 00064f 000644 000635 000651 000628 00064f 000631 000631 00064b 000020 000963 000020 000963
...with 000068 000020 000963 000020 000963 000020 005197 following it (I quit translating too early)
which, encoded as UTF-16, is
0050 006f 0077 0065 0072 0020 0644 064f 0644 064f 0635 0651 0628 064f 0644 064f 0644 0635 0651 0628 064f 0631 0631 064b 0020 0963 0020 0963
...with 0068 0020 0963 0020 0963 0020 5197 following it.
As UTF-16, there are no surrogate pairs, so the bug presumably isn't a problem with handling UTF-16-encoded Unicode characters bigger than 00FFFF.
Still true with the corrections.
Re: (Score:3)
Re: But Macs "just work", right? (Score:2, Insightful)
Why? One big reason...
What percentage of current-generation Android phones will be able to get the next 2-3 major releases of the OS?
5-10% ?
What percentage of current-generation iPhones will be able to get the next 2-3 major releases?
~100%.
The apple phone does everything I need it to, and because of OS fragmentation on the Android side, third party apps are typically better / more stable. (Exceptions always exist, of course.)
I'm quite happy to hear arguments to the contrary, but my broad-brush perspective
Re: But Macs "just work", right? (Score:4, Funny)
I'm willing to accept a garden with walls if it means I don't have to constantly worry about what unpatched vulnerability is ripe for exploitation on my phone.
You mean like that vulnerability where I can send you a text message and cause your phone to crash? ;-)
Re: (Score:2, Troll)
Wasn't It Android the main ingredient of a botnet half a million strong a couple of years ago?
Re: (Score:3)
Judging from the negative mod I got for my remark, the answer is yes, I was right, and yes it was inconvenient for the Fandroids out there.
Have nice day. [rt.com]
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Yes, iOS is protected from this sort of attack by simply not allowing the user to install from unknown sources, a setting which is disabled by default on Android, incidentally. In other words, one specifically has to make themselves vulnerable to this attack in order to be
Re: (Score:2)
I'm willing to accept a garden with walls if it means I don't have to constantly worry about what unpatched vulnerability is ripe for exploitation on my phone.
You mean like the ability to crash a phone with a text message? :)
Re: (Score:3)
What percentage of current-generation iPhones will be able to get the next 2-3 major releases?
~100%.
How many of those phones, after receiving 2 or 3 major releases, will be so buggy or sluggish as to be unusable? Considering the amount of bitching every time it happens, I'd say non-zero.
Re:But Macs "just work", right? (Score:5, Insightful)
Never. Ever. Do. That. Again.
Or I will mark you as a troll if I have mod points. And frankly, I hope somebody does that to this one.
If you're going to post an informative link from Wikipedia, go straight to Wikipedia; not that wikiwand crap. Using that link to a site pushing a formatting extension that changes the way wikipedia's UI format looks is trolling for users to hijack with a MitM attack. This is fucking /. The general population knows better than to install random extensions from unverified sources. Go pedal your crapware on reddit.
Re:Is it 2013 again? (Score:4, Interesting)
No, it's 1985 again. Or even earlier. 1985 was when I found out an escape sequence that would reboot the HP100 portable computer my boss used to access the message system on the HP 3000 minicomputer. Cue me sending an email with it in the subject. The reboot took so long the messaging system logged you off and handily when you log in it prints the subjects of your unread emails and around you go again.
This kind of stuff never gets old.
Re: (Score:2)
Ha ha ha ha...
Not that it's funny or interesting in any way, but thought I'd give you the maximal boost in self-esteem that you were hoping for, Mr. "un-moron."
Re: (Score:3)
Yeah, that was the point I was trying to get at. Most people take the privacy of their most intimate secrets for granted - they keep it in their email, on their mobile devices etc. And while these things are pretty well guarded, from a technological standpoint a single bug can lead to the mass subversion of a whole ecosystem. It seems to me that the day all of Gmail - or some other major email provider, or private data on everyone's iPhones, etc. is hacked and made public, will be an historic event "The da
Re: (Score:2)
Yeah, that was the point I was trying to get at. Most people take the privacy of their most intimate secrets for granted -
Or they simply don't care as much as you do. Seriously, you think anyone really wants to see photos of your bum? Who is the market for all this tonnes and tonnes of useless information?
If all the world's secrets were published tomorrow I think the reaction would be "meh, what's for dinner?" It's actually worse if it only happens to one person, if happens to everyone then that becomes the new norm and no-one cares.
Re: (Score:2)
I'll force one text format and one only for all glyphs in existance (UTF seems like a good candidate).
To which UTF are you referring?