Slashdot Mirror
A Text Message Can Crash An iPhone and Force It To Reboot
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.
This is why you always sanitize user input.
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
Unicode, no doubt. It's not really all that simple.
Yes, technically there is a way to execute phone specific code with specially crafted text messages. This is not doing that. It's not executing a program. The system is trying to abbreviate the contents of the message to display in a notification banner or on the lock screen through a widget (or whatever apple calls them). The system is doing something it's designed to do, but due to lack of foresight or just shoddy development, they never bothered testing this with special characters. And some clown obviously found the bug. This is actually pretty big. So in the past few months I've learned about 3 important issues with IOS devices, even those running the current release: 1)They are still including a chinese root cert that has been delisted for handing out forged google certs, and who knows what else. 2)A specially crafted access point being in range of your IOS device can cause it to become unstable and eventually crash, even if you have not connected to that network 3)A specially crafted text message can crash your phone upon receiving it. Lets be clear, I'm not saying Android doesn't have some major issues as well, so don't try to fanboy me. But this is not what I expect from Apple. This is just bad. Lack of sanity testing? Keeping their users at risk seemingly just to say FU to google?
SJW: had to look it up myself.
no simple text can be parsed by a program are you still amazed?
https://xkcd.com/327/
I still laugh at this... am I an idiot? Don't answer that.
You have to give up 2x battery life to get the same performance? What kind of shit hardware do you buy?
Yes, there are special types of SMS the carrier can use to send commands to your baseband chip.
Getting notifications on an Apple Watch also protects the iPhone from the bug.
They have to push sales of the iWatch some ways...
They do not publish it in TFA.
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 will be executed as part of the app...
There are ways to mitigate that — such as by declaring data-parts of memory non-executable — but the earlier successful exploits of buffer overflow in the image-parsing code suggest, Apple is not using this.
Security — as any good work in general — is hard. Disproportionally harder than the merely Ok work. The real measure is not the number of bugs, really, but the speed of the fixes, once the problems are discovered. Unfortunately, Apple seems to be slow at that too...
In Soviet Washington the swamp drains you.
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.
POTUS Witch Hunt tracker: 75 charges filed against 19 witches, 4 witches cooperating and 5 witches have pled guilty.
This story feels familiar...maybe one of the best reasons to avoid iOS devices. https://www.youtube.com/watch?...
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.
Confused or want karma points, probably the latter.
"The bug is being used as a prank, with users taking to Twitter to vent their frustration after crashes. As with any glitch like this, it is that possible hackers could turn the bug into a method of attack beyond simple pranks." Seems to me if you can crash a device, you can perhaps "root" a device. Sounds like this is a test to see what can be done to an iOS device both now and in the future.
Trying around the office.
For example:
(in a non-Western language)
We know what we have to do next...
Crash!
An sms that uploads the recipient's email and photos on bittorrent, or on top of a blockchain. That should be a trend setter...
Right. They never bothered testing for a particular string that was found 8 years after the iPhone's release.
Could you be more stupid?
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.
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.
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 is that while Apple's ecosystem is a walled garden, Android's ecosystem is the wild west.
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.
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.
The real "Libtards" are the Libertarians!
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 that.
Unless Apple tested with every possible combination of characters, or had a test case which exactly matched this, I can easily see this being something which would get missed.
Lost at C:>. Found at C.
Yes, technically there is a way to execute phone specific code with specially crafted text messages.
"Click here to install a puppy screensaver!!!"
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
Power h
I've had HTC and Android phones, neither had any great claims to battery life.. except that you could remove the battery and have a spare available. As for laptops, if they cost less than a Mac, they certainly don't have comparable battery life.
I've had a couple android phones from HTC and Samsung, they were fine with supported releases until they were 6 months old. After that it was pathetic. And I realize that's a vendor / carrier complicated issue, but it's the end result that matters.
I mean seriously, why is it Apple again screwing up with Unicode? It's the third example of such crash that I recall, and probably there were more.
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? ;-)
I wish I were as sure of anything as some people are of everything
"Android is a superior OS"
"I think my iPhone has a bug"
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 are treated specially, then they are part of the specifications, and should factor in to the choice of categories. There is software to automate building of test cases based on the categories, and the testing could be automated as well.
If we only test likely cases, we are not doing security testing. Given that this is an unauthenticated network vector, it should be subject to security testing. Apple has the resources to do this.
You don't understand software security testing. See my reply to gstoddard.
AOL!
Probably the usual buffer overflow.
These days, system designers are fairly good about separating code and data, and making it impossible to execute data, but the one place they refuse to address the issue is on the stack, which contains code pointers, which are essentially "goto" instructions, and thus, they're code. Despite this, they constantly toss data on the stack all of the time, and occasionally people figure out how to send just the right data to a program to cause it to overwrite those code pointers with new code pointers that cause the program to do exactly what they want it to do.
The solution obviously is to have one stack for code, and a separate stack for data. This could be achieved on a PC by simply using the CPU's stack pointer (which it uses to store return addresses) only to store return addresses, and maintaining a separate stack for data, by using a different register to store a pointer on this stack and manually incrementing/decrementing that pointer when the stack is accessed. It would prevent a lot of exploits, but as usual, compiler authors are more concerned with performance than they are with security, never mind that one can buy a faster computer, but one cannot buy a more secure computer.
Obviously I think we should be primarily focused on security, and when security is too slow, we should look to speed up our hardware, not compromise our security. However, I seem to be in the minority on that one. Despite security being in the news every day, people still care more about speed.
So when your phone receives a very specific text in Arabic it... blows itself up?
Shit like this are the artefacts from the steam age of computing.
As a web guy I deal with this every day. If I ever get around to building an OS and/plattform (Harhar) I'll force one text format and one only for all glyphs in existance (UTF seems like a good candidate).
Controll characters will be completely seperate.
We suffer more in our imagination than in reality. - Seneca
This is only true for certain classes of memory management defects. There are many different kinds of defects, and many different ways to crash software that bring no possibility of remote code execution.
Let me guess: you're into Agile development, but don't understand it well enough to know why black-box testing isn't enough for high-reliability applications.
Quidnam Latine loqui modo coepi?
For complicated c9mbos, perhaps. But random string generators should relatively quickly stumble across an elipsis in the middle of Latin or Arabic characters.
I wouldn't a priori suspect a string display routine to have a problem, but the guy who wrote it to do some gymnastics switching character sets should, and should have run such a test in a debugger ready to trap bad memory accesses.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
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 how one could forget something about that in their implementation. Then again, between Emoji and Asian languages, its kinda hard to ignore dealing with those.
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.
Whitebox testing would point to exercising an ellipsis if treated specially. But good old blackbox billions of random strings should stumble across an ellipsis surrounded by non-Latin script characters, and fairly quickly.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
" As for laptops, if they cost less than a Mac, they certainly don't have comparable battery life."
I've got a 75 MHz Pentium. With an upgraded battery pack, it runs for almost 48 hour straight.
Please show me ANY Apple laptop that gets that sort of battery life. Oh, they're only JUST NOW getting made with that sort of low power envelope.
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? :)
"You're reading it the wrong way."
Welcome to the Panopticon. Used to be a prison, now it's your home.
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.
POTUS Witch Hunt tracker: 75 charges filed against 19 witches, 4 witches cooperating and 5 witches have pled guilty.
Wasn't It Android the main ingredient of a botnet half a million strong a couple of years ago?
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
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.
While I understand where you are coming from, I think what the poster meant is only a moron would believe testing will find all bugs, security or otherwise.
LOLOL apples to oranges. Let me see you multitask on that laptop like i do on Mac. I paid $1200 for my 2012 mbp i7. I was looking at an i7 laptop with similar specs to run Linux, $900. I might as well spend the extra $300 and get all the perks that come with apple. If $300 is setting you broke, then you need a new job.
Yes, which in 8 years of using an iPhone has never once happen to me. And probably will never happen to me.
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.
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 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.
https://www.reddit.com/r/iphon...
"If any question why we died, Tell them because our fathers lied."
Wouldn't a message in all Chinese trigger this?
Or if it has to do with splitting a multi byte character.,all Chinese and an odd number of Latin thrown in (I see snippits of Latin characters on weibo all of the time ).
If the error is not likely to happen, there's more too it than being explained.
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
The correct answer is 0%, not 100%.
Major features are left out for no good reason, like voice assistant. It's not like it was missing hardware, and the original app it was based on worked with even first gen phones (and even Android was almost done before the buyout)
Moreover, Android's individual components and system apps are updated outside of major OS revisions. That fraudulent SSL Cert issuer in China like a month or two? That was fixed without a full system update in under a week. Meanwhile, you're STILL waiting... and your information can be siphoned off pretty easily with a forged cert.
You can keep your hyperbole... I'll keep to my security.
Or mine 867-5309.
Oh Jenny.
"If any question why we died, Tell them because our fathers lied."
Is this any relation to the way SMS messages from (some) iPhones appear on the Treo message screen as a single non-ASCII garbage character?
It's unpredictable, but once someone's iPhone starts they can never again send me a SMS.
And as a dinosaur, I only started using SMS last year.
No, I don't want a new telephone, I'm happy with my Treo 650....
LOL, if you buy a non-flagship phone, what are you expecting?
I'm not sure what you're referring to. Even old flagship (and a decent portion of non-flagship) Android devices have at least 1, if not 2 years updates before the features are just too much for the aging phone (in which case, it still gets security updates because most system apps can be updated through Google Play.
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.
"Because nobody uses hosts files for security" - by bouldin (828821) on Thursday May 21, 2015 @05:53PM (#49746865)
FROM -> http://it.slashdot.org/comment...
SpyBot S&D does dimwit
(you FAIL #1)!
You LATER deny it's spybot's forums http://it.slashdot.org/comment...
Anyone can use it + see they do & MANY use that program stupid!
(you FAIL #2)!
---
NOD32/ESET's says hosts = valuable security http://slashdot.org/comments.p... as I also "overturned a SECURITY expert" on a "false positive" on my Hosts program RIGHT there & he gave in!
(YOU FAIL #3)!
(Had to - MalwareBytes' employees VETTED my code & even host + HIGHLY RECOMMEND it for me near top of -> http://hosts-file.net/?s=Downl...
---
Mr. Oliver Day of Symantec/Norton/SecurityFocus does too http://www.securityfocus.com/c...
(you FAIL #4)!
YOU ALSO TRIED TO DENY it & it's there in PLAIN Black & White with his NAME on it!
"I don't see Oliver Day of SecurityFocus on there. Weren't you going to cite him?" - by bouldin (828821) on Thursday May 21, 2015 @08:43PM (#49747763)
FROM-> http://it.slashdot.org/comment...
(you FAIL #5)!
---
WHOSE INITIALS ARE ON THIS - WINNER IN 2008 (added proof of paid for good layered security article):
http://forums.pcpitstop.com/in...
(YOU FAIL #7)!
Via the layered security/defense in depth methods my security guide extolls? I've COMPLETELY shut down your "desperation" RARE edge cases you tried too!
(You FAIL #8)!
Do YOU have *ANYTHING* like it to YOUR name/credit? No.
(YOU FAIL #9)!
---
Do you write a ware that noted security pros even seconded me on?? No.
(You FAIL #10)!
A ware that not only secures you but ALSO SPEEDS YOU UP (e.g. unlike antivirus which is not as effective anymore vs. online modern threats, mine is, stopping sources of infestation BEFORE they can get into you, & IF in you, stopping their communications BACK to C&C servers too!)
APK
P.S.=> LMAO: "Bouldin's GOLDEN top 10 'greatest hits'" (fails vs. me)... apk
"Because nobody uses hosts files for security" - by bouldin (828821) on Thursday May 21, 2015 @05:53PM (#49746865)
FROM -> http://it.slashdot.org/comment...
SpyBot S&D does dimwit
(you FAIL #1)!
You LATER deny it's spybot's forums http://it.slashdot.org/comment...
Anyone can use it + see they do & MANY use that program stupid!
(you FAIL #2)!
---
NOD32/ESET's says hosts = valuable security http://slashdot.org/comments.p... as I also "overturned a SECURITY expert" on a "false positive" on my Hosts program RIGHT there & he gave in!
(YOU FAIL #3)!
(Had to - MalwareBytes' employees VETTED my code & even host + HIGHLY RECOMMEND it for me near top of -> http://hosts-file.net/?s=Downl...
---
Mr. Oliver Day of Symantec/Norton/SecurityFocus does too http://www.securityfocus.com/c...
(you FAIL #4)!
YOU ALSO TRIED TO DENY it & it's there in PLAIN Black & White with his NAME on it!
"I don't see Oliver Day of SecurityFocus on there. Weren't you going to cite him?" - by bouldin (828821) on Thursday May 21, 2015 @08:43PM (#49747763)
FROM-> http://it.slashdot.org/comment...
(you FAIL #5)!
---
WHOSE INITIALS ARE ON THIS - WINNER IN 2008 (added proof of paid for good layered security article):
http://forums.pcpitstop.com/in...
(YOU FAIL #7)!
Via the layered security/defense in depth methods my security guide extolls? I've COMPLETELY shut down your "desperation" RARE edge cases you tried too!
(You FAIL #8)!
Do YOU have *ANYTHING* like it to YOUR name/credit? No.
(YOU FAIL #9)!
---
Do you write a ware that noted security pros even seconded me on?? No.
(You FAIL #10)!
A ware that not only secures you but ALSO SPEEDS YOU UP (e.g. unlike antivirus which is not as effective anymore vs. online modern threats, mine is, stopping sources of infestation BEFORE they can get into you, & IF in you, stopping their communications BACK to C&C servers too!)
APK
P.S.=> LMAO: "Bouldin's GOLDEN top 10 'greatest hits'" (fails vs. me)... apk
I'm having flashbacks of 90's Yahoo boot wars. Malicious text strings, sound bytes, bots, flooding, invite spamming, account locking, and illegal account name trading. Man those were some fun times.
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:
I've had more than my share of these sort of experiences too.
UTF-16 is dangerous, and should be phased out as much as possible. Where absolutely needed for performance reasons, it should be an internal representation only, hidden from the developer as much as possible. In particular, "length" functions should return the actual string length in characters, not code units; indexing functions should take character offsets; not code unit offsets; and returned "single characters" exposed to the developer should be of a format capable of handling multi-code-unit glyphs. Anything involving working with actual singular UTF-16 code units should only be available as a "for advanced users only, use at your own risk" functionality.
POTUS Witch Hunt tracker: 75 charges filed against 19 witches, 4 witches cooperating and 5 witches have pled guilty.
Duh.
-- Tigger warning: This post may contain tiggers! --
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 ...
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Troll? Fucking moron moderator didn't get the joke. Cum sucking idiot!
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.
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
To be fair, Swift's string type actually deals with all the above problems correctly.
I came here to say exactly this!
Why is everyone misusing the mantra of "always sanitize user input"? This is a generic messaging app. There is no invalid input!
If the application crashes because of assumptions about how to truncate messages (or because of assumptions that truncated messages will always contain complete multibyte sequences) then fix the assumptions!
Fuck off.
it's a parsing bug
Yes! correct!
what difference would sanitizing user input make...
I'm glad you asked! It might make a huge difference to Apple's revenue stream. Clearly Apple hasn't sufficiently monetized SMS/iMessage. Once "sanitization" is allowed -- once content is subject to being modified for conformity -- a whole new world will be within their reach.
"hey, bring some soda for the party" INVALID
"hey, bring some Coke for the party" SANITIZED
</tinfoilcynic>
Maybe this will also crash the NSA sniffing programs.
I'm a satanic clam.
YOU brought it on YOURSELF: "eat your words" http://slashdot.org/comments.p... and You're JUST like that OTHER "pseudo security engineer" raymorris I tore to SHREDS here http://it.slashdot.org/comment... with concrete, reputable & reliable, UNDENIABLE sources + facts & truth...
APK
P.S.=> Shouldn't have "tried me" Bouldin - I warned you, way, Way, WAY AHEAD OF TIME what the outcome would be... you FAIL, boy! apk
C++ has UTF-8 string literals nowadays, you write them as u8"Text"
Citation, please? I don't recall this.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Amusingly Slashdot did cover that. It's like there's some weird blind spot when it comes to weaknesses in Android.
You lot really should show a little more objectivity. It doesn't hurt anything.
"Nobody uses hosts files for security" - by bouldin (828821) on Thursday May 21, 2015 @05:53PM (#49746865)
FROM -> http://it.slashdot.org/comment...
SpyBot S&D does dimwit
(you FAIL #1)!
Anyone can use it + see they do & MANY use that program stupid!
(you FAIL #2)!
---
NOD32/ESET's says hosts = valuable security http://slashdot.org/comments.p... as I also "overturned a SECURITY expert" on a "false positive" on my Hosts program RIGHT there & he gave in!
(YOU FAIL #3)!
(Had to - MalwareBytes' employees VETTED my code & even host + HIGHLY RECOMMEND it for me near top of -> http://hosts-file.net/?s=Downl...
---
Mr. Oliver Day of Symantec/Norton/SecurityFocus does too http://www.securityfocus.com/c...
(you FAIL #4)!
YOU ALSO TRIED TO DENY it & it's there in PLAIN Black & White with his NAME on it!
"I don't see Oliver Day of SecurityFocus on there. Weren't you going to cite him?" - by bouldin (828821) on Thursday May 21, 2015 @08:43PM (#49747763)
FROM-> http://it.slashdot.org/comment...
(you FAIL #5)!
---
WHOSE INITIALS ARE ON THIS - WINNER IN 2008 (added proof of paid for good layered security article):
http://forums.pcpitstop.com/in...
(YOU FAIL #7)!
Via the layered security/defense in depth methods my security guide extolls? I've COMPLETELY shut down your "desperation" RARE edge cases you tried too!
(You FAIL #8)!
Do YOU have *ANYTHING* like it to YOUR name/credit? No.
(YOU FAIL #9)!
---
Do you write a ware that noted security pros even seconded me on?? No.
(You FAIL #10)!
A ware that not only secures you but ALSO SPEEDS YOU UP (e.g. unlike antivirus which is not as effective anymore vs. online modern threats, mine is, stopping sources of infestation BEFORE they can get into you, & IF in you, stopping their communications BACK to C&C servers too!)
APK
P.S.=> LMAO: "Bouldin's GOLDEN top 10 'greatest hits'" (fails vs. me) - & you're a "security-engineer"after the above? LOL, not... apk
I'm not denying it, I'm asking for a link to an article about it, as I legitimately don't recall having heard or read about it at the time. How about being helpful, instead of being a douche, for once?
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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.
There's no place I could be, since I've found Serenity...
Oh! It was this? Huh, interesting. FTFA: "Users would then see notifications about the finished downloads and would click on them, prompting the malicious application to install if their devices had the "unknown sources" setting enabled"
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 vulnerable, it doesn't work in Android's default configuration.
It's always amusing when Apple fanbois point to vulnerabilities that require the ability to install from untrusted sources and scream about how insecure Android is. Really? Don't check the box to allow it (which, again, is unchecked by default) and it's a non-issue; the only people who should be checking that box are Android developers and, then, only on their development and testing devices.
The other class of "exploits" I find laughable are those that require root. Sure, many of them can be found in the Play store, but they have no effect whatsoever on a stock Android install. If you're going to consider those "exploits" you need to compare against the iOS equivalent: jailbroken devices. Suddenly, Android doesn't look so bad.
Sent from my Space Gray iPad Air 2.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Nobody cares. Everyone knows you're a complete idiot.
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.
I'm quite happy to hear arguments to the contrary, but my broad-brush perspective is that while Apple's ecosystem is a walled garden, Android's ecosystem is the wild west.
How would you classify a Windows desktop or a Linux desktop?
Ah, resident malware author and all round wanker APK.
Yeh, you're just good for a nostalgic laugh with your inferiority complex.
It's always amusing when Apple fanbois point to vulnerabilities that require the ability to install from untrusted sources and scream about how insecure Android is. Really?
Yes, if you leave out the number '500,000' it sounds silly, doesn't it. It doesn't at all sound like the result of bad philosophies colliding, thus breeding bad behavior from a massive number of customers.
Oh, just wanted to mention since I'm somehow a douche for your laziness, you replied a full hour after the link you asked for was presented. Apple fanboys are accused of succumbing to the Reality Distortion Field, apparently Fandroids are especially vulnerable to SEP.
The resolution to the problem, until Apple comes up with a fix, is to turn off Preview and Banners in Messages,
Go to Settings > Notifications > Messages
set "Alert Style" to "none' and turn off the switch for "Show Previews".
This will prevent the malicious text from being sent to the screen, which then fails to be able to complete the subroutine, causing a respring that then causes the iPhone to reboot and occasionally crash Messages.
You will still know when you are getting an incoming text from the "ding" [or what ever other noise you have assigned it} and the icon badge showing a new text message has come in... you just won't see a preview of it.
When Apple gets the fix distributed you can turn the setting back on.
The 90% of phones that don't though are probably at least 50% cheaper than the iPhone, and I'm sure if the announcement is true, vendors will begin to make the same guarantees for other Android phones too.
Now, the best thing about the walled garden, is that when a serious problem is found with the app after release, it can take Apple a long time to approve the update.
That's also excluding the fact that people on iPhone don't realise jailbreaking is basically exploiting vulnerabilities in the phone, and that there have been plenty of security issues discovered on iPhone (ranging from SSL related, to image parsing)
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.
"Nobody uses hosts files for security" - by bouldin (828821) on Thursday May 21, 2015 @05:53PM (#49746865)
FROM -> http://it.slashdot.org/comment...
SpyBot S&D does dimwit
(you FAIL #1)!
Anyone can use it + see they do & MANY use that program stupid!
(you FAIL #2)!
---
NOD32/ESET's says hosts = valuable security http://slashdot.org/comments.p... as I also "overturned a SECURITY expert" on a "false positive" on my Hosts program RIGHT there & he gave in!
(YOU FAIL #3)!
(Had to - MalwareBytes' employees VETTED my code & even host + HIGHLY RECOMMEND it for me near top of -> http://hosts-file.net/?s=Downl...
---
Mr. Oliver Day of Symantec/Norton/SecurityFocus does too http://www.securityfocus.com/c...
(you FAIL #4)!
YOU ALSO TRIED TO DENY it & it's there in PLAIN Black & White with his NAME on it!
"I don't see Oliver Day of SecurityFocus on there. Weren't you going to cite him?" - by bouldin (828821) on Thursday May 21, 2015 @08:43PM (#49747763)
FROM-> http://it.slashdot.org/comment...
(you FAIL #5)!
---
WHOSE INITIALS ARE ON THIS - WINNER IN 2008 (added proof of paid for good layered security article):
http://forums.pcpitstop.com/in...
(YOU FAIL #7)!
Via the layered security/defense in depth methods my security guide extolls? I've COMPLETELY shut down your "desperation" RARE edge cases you tried too!
(You FAIL #8)!
Do YOU have *ANYTHING* like it to YOUR name/credit? No.
(YOU FAIL #9)!
---
Do you write a ware that noted security pros even seconded me on?? No.
(You FAIL #10)!
A ware that not only secures you but ALSO SPEEDS YOU UP (e.g. unlike antivirus which is not as effective anymore vs. online modern threats, mine is, stopping sources of infestation BEFORE they can get into you, & IF in you, stopping their communications BACK to C&C servers too!)
APK
P.S.=> LMAO: "Bouldin's GOLDEN top 10 'greatest hits'" (fails vs. me) - & you're a "security-engineer"after the above? LOL, not... apk
"ILLOGIC logic" + ad hominem attacks != a defense vs. http://slashdot.org/comments.p... showing your MASSIVE blunders on SECURITY Bouldin IN YOUR OWN WORDS QUOTED as UNDENIABLE PROOF thereof! as to my statement of FACT on that very account, lol!
(Man - after THAT debacle you brought on YOURSELF? Hey - there's NO WAY you can be a 'security engineer' & educated @ a GOOD school for it - lmao, no way, OR you just SUCK @ the field & are a green, wet-behind-the-ears ROOKIE NOOB... take your pick, either way? YOU FAIL!)
APK
P.S.=> You brought it on yourself vs. "The LORD of HOSTS"... apk
MalwareBytes' hpHosts Admin (MalwareBytes TOP employee) hosts & recommends it -> http://hosts-file.net/?s=Downl... & MalwareBytes = BEST antivirus http://www.av-test.org/en/news... UNDER THE SUN!
(Clue: The ,b>man's SEEN & VERIFIED 100% that my sourcecode & program ARE SAFE, even has a copy he keeps for me...)
APK Hosts File Engine 9.0++ SR-2 32/64-bit -> http://start64.com/index.php?o...
Yes - He's a GOOD man & checked it, even helping me disprove SEVERAL false positives (since he knows the major antivirus companies' guys too)
So far, the ones I've turned over "false positives" on are:
Qihoo360
EmsiSoft
ArcaVir
ESET/NOD32 (see below)
Comodo
McAfee
Sophos
* So much for "security engineers" & "experts" like Bouldin especially vs. the likes of them "going MY way", fool...
APK
P.S.=> Bouldin, are YOU senile too? YOU KNOW THIS from Aryeh Goretsky of NOD32/ESET an enterprise class widely recognized GOOD antivirus (he posts on /. too, mind you): He was one I overturned (good guy though on it & FAIR) & HE TOLD YOU "hosts are a GOOD effective defense vs. malware"!
Refresh your FAILING fail memory -> http://slashdot.org/comments.p... , dolt... lol & "EAT YOUR WORDS"...
... apk
See subject: You project you care after this http://slashdot.org/comments.p...
* The "unidentifiable ac posts" too? Please... talk about OBVIOUS that's "the best ya got" vs. "The LORD of Hosts" in myself, Bouldin...
APK
P.S.=> Once more: YOU brought all this ON YOURSELF & the Score = APK 16, Bouldin 0 since you can't prove my points on hosts wrong validly & technically AT ALL, lol... some 'security engineer' YOU are (not, no way, not after the above MESS you made of things)... apk
Bouldin's understanding of security is inferior http://slashdot.org/comments.p... and after I read that I can safely make that statement based on Bouldin's own mistakes quoted that he made 10 times there against apk without a doubt.
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 the text is simply idiotic, and interferes with the main reason (communication between literate people) that Unicode was invented.
(And we might note that a significant fraction of the users of the Internet now consists of people who communicate via Hanzi text, or Arabic or any of the hundreds of other character sets that humanity uses to communicate. Damaging those folks' texts to avoid fixing your crappy software is a good way to tell them that you don't want them communicating with other people. This is rapidly becoming a commercially untenable position for people trying to "attract eyes" on the Net. ;-)
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
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 iterators for other normalization forms. In all cases these would return negative numbers or some value that cannot be confused with a code point for UTF-8 error bytes.
This would be very fast because you can find the next Unicode code unit or whatever in constant time. Any api where you can arbitrarily index a unit using an integer is not going to be constant, it will be linear with that integer. Iterators avoid this.
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. This means you cannot trust arbitrary 8-bit data to survive translation to "Unicode" and back. This has been the source of endless bugs and is the reason people can't use Python 3.0.
We have to have something, though. Not everybody writes in English.
POTUS Witch Hunt tracker: 75 charges filed against 19 witches, 4 witches cooperating and 5 witches have pled guilty.
I like that idea. You're right, it should be pretty efficient to implement, regardless of the string's backend encoding. And the value represented by the iterator will, by nature of being implemented as a pointer to a certain part in the string, be able to point to a glyph of arbitrary length (unlike a getter function with a fixed-length return type). Being an iterator it'll fit into all standard c++ libraries that take iterators.
It would be nice to have it be a random-access iterator so that you can jump to an arbitrary offset. There's a lot of optimizations they could do internally to help facilitate that. But obviously you still want to let programmers choose - by some means or another - whether they want such unicode optimizations (or unicode iteration, or so forth). Because while the overhead they'd impose wouldn't be huge, there still would be overhead.
POTUS Witch Hunt tracker: 75 charges filed against 19 witches, 4 witches cooperating and 5 witches have pled guilty.
Completely possible to keep a phone restarting. Sending the message every 8 seconds results in a reboot loop. The only thing you can do at that point is find a place with no cell service to add the sender to the block list, or from a mac machine running continuity...
Nice job Apple, you have screwed up worse than Windows ever did. You made it possible for non-technical people to take down a system.
Yes, we have UTF-8. You do know that it can hold non-English, right?
I don't think there are any useful algorithms that need random access, except for searches that do not require the index to be "exact". Therefore you certainly do not need a reliable string[i]. You can make it return a pointer to byte i, which will work for most uses (ie searches for ASCII and replacing one ASCII byte with another).
Some complex searches do want to jump arbitrary amounts ahead, but do not require any "exact" location. Instead they want "a character near the middle" and so forth. In this case it might be useful to produce an iterator that points near byte i. A simple UTF-32 one would jump to byte i and then back up to the last non-continuation byte, unless there are 3 or more in which case it would stay where it first went (as that is the start of an error). Ones that return normalization forms would be much more complex. Something like this:
utf16_iterator i(string, string.length()/2);
UTF-8 is an encoding of unicode, so I'm totally not getting your "Actually I think "Unicode strings" should be avoided completely."
POTUS Witch Hunt tracker: 75 charges filed against 19 witches, 4 witches cooperating and 5 witches have pled guilty.
I would love a sed command that would replace all these worthless shitposts on ANY character-related topic, with an empty set. Or maybe a confused baby emoji.
"Oh, but not everyone speaks in English!". Of course not. That's never the fucking topic. Shut. The. Fuck. Up.
You and all the others like you can just excuse yourself from encoding discussions, and most the fuck CERTAINLY regex discussions. None of which are ever about what you guys think they are. That would be delish.
Agree totally, but it would be nice to add some utf-8 specific functions that will, in ONLY those cases, actually walk the data (vastly slower for very large inputs than an index) and generate data about the string as utf-8 instead of byte data. Maybe those already exist in C/C++/ whatever the kids laughably think will be the next thing over those.
http://pages.telemessage.com/acton/fs/blocks/
A lot of misinformed programmers use the term "Unicode" to mean encodings other than UTF-8, typically UTF-16 or UCS-2. For instance a function called "toUnicode" often is a translator from UTF-8 to UTF-16. Therefore when people say "Unicode strings" they almost always mean non-byte strings. I propose the best solution is to eliminate all such strings. It is true that byte strings would encode UTF-8 and thus be "Unicode" but the hope is that this would be so standard that there would be no need to ever specify this and they would be called "strings".
So you mean get rid of wide-character encodings and only use UTF-8 where unicode characters are needed? I agree. :)
POTUS Witch Hunt tracker: 75 charges filed against 19 witches, 4 witches cooperating and 5 witches have pled guilty.
Ah an unidentifable not courageous ac loser limey projects he's a wanker!
Yes, if you leave out the number '500,000' it sounds silly, doesn't it.
And the only reason the number of exploits from untrusted sources is 0 on non-jailbroken iOS is because you simply can't install from untrusted sources.
Since you seem to want to compare Apples to Androids, though, here is one that infected 100k+ iOS devices, no jailbreak or untrusted sources required. And another affecting 75k+ jailbroken iOS devices. I stopped searching after finding those two (which took a whole 30 seconds); that it was so easy to find those two tells me there's a lot more to be found if I wanted to invest another half-minute in it.
Let's see, 500k of 900 million Android devices, that's an infection rate of about 5.6%. I'll admit, that's not great, but let's see how iOS fares before we got all uppity, okay? I can't find "in use" numbers, only that Apple has sold over 800k; I know they're not all in use, so I'll do a quick calculation based on market share. Worldwide market share, that is, since the 500k number you're touting is worldwide. So, Android's 81.5% market share means that 1% of the market is a hair over 11 million devices; iOS holds 14.8% of the market, or 163.5 million devices. 175k infected, out of 163.5 million devices, that's a 10.7% infection rate.
So yes, sure, let's assume that other malware exists for iOS, sure there are almost 3x as many infected Android devices, but an iOS device appears to be almost 2x as likely to be infected. Factor in that other malware certainly does exist (every jailbreak is an exploit and many jailbreak utilities have been bundled with malware; little reported but anyone involved in the scene knows, always get your jailbreak tools direct from the author, but even that is no guarantee). In short, the 175k number I used is smaller than it should be, making the 10.7% infection rate I came up with a fair bit smaller than the real infection rate, as well.
As a user of a single phone and a single tablet, running the less-likely-infected platform means I'm less likely to be infected. Period. That said, I greatly prefer iOS over Android on a tablet and absolutely love my iPad. I don't do anything mission critical on either device, so my exposure is limited in any case, but I'm a little more lax with my more secure Android phone than I am with my less secure iPad.
It doesn't at all sound like the result of bad philosophies colliding, thus breeding bad behavior from a massive number of customers.
Correct. It really doesn't. unless you consider freedom a bad philosophy. Of course, with freedom comes responsibility, as in you are responsible for what happens when you misuse the freedom to install crap on your phone. Seriously, rather than volunteering to have our own freedoms stripped from us because we refuse to connect our actions with the consequences they bring, why don't we all just behave like the adults that we are and own out own liabilities? Android lets you do that, while iOS does not.
Oh, just wanted to mention since I'm somehow a douche for your laziness, you replied a full hour after the link you asked for was presented.
You're not a douche because I loaded the page long before that link was posted (not laziness, BTW), you're a douche for a whole slew of other reasons, many of which also apply to myself. So I didn't refresh the page before posting. We all do that, your point? Welcome to Slashdot.
Fandroids are especially vulnerable to SEP.
They also wouldn't own an iPad and two MacBook Pros. I guess you aimed your anti-Fandroid ray at the wrong guy.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
So you mean get rid of wide-character encodings and only use UTF-8 where unicode characters are needed? I agree. :)
Yes
Yes, it is embarrasing laziness. Douche projection? And yes, your focus on one side supports the claim against you of bias despite your protestation that some of your best friends... I mean you say you have an iPad.
Hint: Your comically long-winded rant has a very obvious plot-hole. Suddenly you can use Google, but only when properly motivated.
Funny, the post you replied to was the result of my having used Google to track down the story myself, since I did not see your link. Interesting, you know, me being too lazy to Google it and all. Where's this plot hole?
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Uh, yeah, you went to Google after failing to scroll down a bit and being arm twisted into it. Great work there.
As for the plot hole, it really is obvious. I'll give you a hint: In my first post I criticized your objectivity. I described the very affliction that your long-winded, I suppose you'd call it a rebuttal, demonstrated quite hilariously.
Since technically that isn't really a hint because I've already told you this before, here's another. The number isn't one. You've overcome your problem once, let's see if you can do it again.
Uh, yeah, you went to Google after failing to scroll down a bit and being arm twisted into it. Great work there.
Failing to scroll? I loaded the page an hour before the link was posted and replied an hour after (without reloading the page) when I got around to it. I've already explained that; the link wasn't on the page to scroll down to, but nice try. As for arm-twisting, I replied to my own comment directly, before anyone else had replied to it in order to be able to twist my arm. Another good try, but you're not quite on the mark.
As for the plot hole, it really is obvious. I'll give you a hint: In my first post I criticized your objectivity.
Yes, you're arguing against me as a person, rather than my point. That tell me you have no fact-based argument.
I described the very affliction that your long-winded, I suppose you'd call it a rebuttal, demonstrated quite hilariously.
You mean that I googled around for some actual facts to post, then explained how those facts apply to reality? What affliction is that, then? Being a realist?
If you disagree with the point I am trying to make, which I have backed up with actual facts, then please, make your own counter point and back it up with your own actual, real, facts. Attacking me because you can't do that only makes your position look as weak as it you and I both know it actually is. Lucky for you, I respond because I find your attempts at trolling me every bit as amusing as you do.
Since technically that isn't really a hint because I've already told you this before, here's another. The number isn't one. You've overcome your problem once, let's see if you can do it again.
This makes no sense. If you used more bold text I'd think you were APK.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
The reason it doesn't make sense is that you feel you can do no wrong. The point I've been making all along is that you have a blind spot when it comes to the research that you do. You're willing to scrutinize one side, but not another, even to the extreme of trying to sell the excuse of not refreshing a page in a discussion forum for an hour. For example, you made your calculation of unfection based on the idea that there is only one bit of malware on Android. You didn't even try looking that up, you just wanted to find a number to lessen its impact. Nice objectivity, there.
Sorry for the late reply, Slashdot stopped notifying me about this thread.
I spent just as long looking for examples of Android malware as I did looking for examples of iOS malware. I admitted, early on, that neither was exhaustive. If you want exhaustive, I'll give it to you, but you won't like the results. Shoot me an email so I can get the entirety of my research and findings to you in a month or two when I'm done. Meanwhile, realize that you're the one with the blind spot; if you don't like my research, do your own and prove mine wrong, don't just point fingers and say "your methodology is flawed", sure it's flawed, I admitted as much at the start, but you still fail to disprove my findings.
As for your insinuation that I feel I can do no wrong... Really? Review my post history, I admit I'm wrong on here whenever someone actually shows me that I am, which happens, roughly, 5 or 6 times a year. If that number seems a bit low it's because I generally don't open my mouth unless I'm fairly certain I know what the hell I'm talking about. You should try it sometime.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.