Slashdot Mirror
Samsung Phones Are Spontaneously Texting Users' Photos To Random Contacts Without Their Permission (theverge.com)
Some Samsung smartphones are randomly sending pictures from the device to a user's contacts without explicit permission, according to users and media outlets. From a report: Users are complaining about the issue on Reddit and the company's official forums. One user says his phone sent all his photos to his girlfriend. The messages are being sent through Samsung's default texting app Samsung Messages, and the photos are being sent as SMS messages. According to reports, the Messages app does not even show users that files have been sent; many just find out after they get a response from the recipient of the random photos sent to them. Samsung told the news outlet it was aware of the issue and was looking into it.
*Looks down at LG V30* "Good boy"
How's that agile development coming along?
A followup question is: How many wang pics were sent out because of this?
How's that agile development coming along?
I assume from this comment you've never gotten an OTA update from your carrier for a Samsung or any other brand. They're months and months between; hardly agile.
Some years ago, a co-worker of mine showed me his Samsung phone. It was a beauty, and he let me play with it for a bit. The hardware was wonderful. The proprietary Samsung crap-ware that was on it was what made me decide that I would never get a Samsung phone. It's just like the branded crap-ware on Windows machines. I have a Nexus 6P and I think it's wonderful. It's Android the way it was intended. Yes, I know Google spies on me.
It's not the release schedule that's Agile, its' the development process...
deleting the extra space after periods so i can stay relevant, yeah.
It's called MMS...
deleting the extra space after periods so i can stay relevant, yeah.
Software doing something quite complicated like crafting a message, sending an attachment etc. is not software being faulty and the execution being corrupt, it's software doing what it was told. The problem likely lies before the software turns from idea into code, so the language is irrelevant. Until we have AI-powered compiler that can analyze human behavior, no language, no matter how modern, should prevent a developper from writting code that do stuff, no matter how silly it is.
Samsung is just trying to show that it cares by connecting you with your friends.
I blame Bixby, about the worst digital "assistant" I've ever seen. I bet that Bixby is "interpreting" actions or words to do something stupid...
Browsing at +1 - no ACs, I ignore their posts. So refreshing!
But TFS erroneously says SMS.
Because that's what's important here, an article using the wrong acronym. FFS YDA AC
I browse on +1 so AC's need not respond, I won't see it.
You didn't mention "marketing". Not sure how, but with Samsung, it's probably some dumb marketing feature gone awry.
I don't know, but it works for me.
I imagine this is probably a troll, but just in case:
The language chosen would have very, very little effect on this. This is a problem with the overall design of the app.
Rust, like Python, Java, Perl, PHP, VBScript, JavaScript, and most other languages, doesn't lend itself to one very specific type of bug called a buffer overflow. That specific issue is mostly just seen in C. Rust is like most languages in that buffer overflow isn't the bug you have to worry about in Rust (or in Perl, PHP, Python, Java, etc.)
What's different about Rust is a very clever marketing thing they did. They took the fact that most languages, including Rust, don't have buffer overflows and hyped it to Trumpian proportions. In marketing material that would make PT Barnum blush, they exclaimed "Rust is secure because it doesn't have buffer overflows! Write all your software in Rust and you'll never have another bug!" Understand this is analogous to saying "spiders are venomous, don't use spiders. Tigers have no venom! If you use tigers, you never have to worry about venom at all. Buy some tigers from us today so you can be safe!"
The problem then is that newbies who don't understand much about programming *think* they're safe because they're using tigers. No need to be careful with tigers because they aren't venomous. Er, I mean no need to be careful when you're using Rust because it doesn't have buffer overflows. That makes it slightly more dangerous, since a lot of people aren't being as careful as they should, thinking Rust is somehow magic.
I maintain a database of every CVE (security bug) ever reported. Well under 1% of them are buffer overflows, so it's a tiny percentage of problems that Rust protects against.
Who gets arrested when it sends out nude selfies from someone under 18? The coders? The CEO of Samsung?
Lawyers love this kind of stuff, lol
as opposed to sending then through SMS?
I browse on +1 so AC's need not respond, I won't see it.
It's possible to activate the various other photo modes by sliding a finger across to the right, then picking the option (Auto, Pro, Panorama, Selective focus, Slow motion, Hyperlapse, Food, Virtual shot, Video collage or Live Broadcast) then pressing the back button. Sometimes that gets activated by accident. I've had my phone switch to front-camera mode simply because of this sensitivity.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
Correct me if I'm wrong, but I assume this software is written in Java, like many Android apps are. Would using a modern programming language like Rust instead of an older language like Java have prevented a bug like this from happening (assuming it actually is a bug that is being reported by these users) in the first place?
I assure you, bad code can be written in any language.
Slashdot your i and slashcross your t.
Considering Samsung's ongoing anti-Apple marketing campaign, this just made me laugh.
Just another day in Paradise
Siegfried & Roy might have thought that, until 2003.
The app is designed to send messages, to contacts, with pictures attached. Obviously that code didn't appear by accident, it was included because that's the purpose of the app. The question is "why is the app doing its thing without being told by the user?" It's as if it's especially prone to "pocket dialing" (or accidental voice dialing?) for some reason.
> This smells like some debugging function left in accidentally
Specifically, a test script. Unit testing could easily have behavior similar to what was described.
> What API would exist that hides SMS messages
The problem is in the messaging app. Where do you see your text messages other than in your messaging app? There is no hiding happening (no active hiding), rather the "display sent message" function is not being run. Normally the messaging app would do two things - display the message the user types and send the message. The app is not displaying messages that the user isn't typing, so that's normal behavior.
Programmers would write separate unit tests to test those two different parts of the program - the local UI would have tests, and sending messages over the network would have separate unit tests. Running the unit test for the internal process for sending an attachment would be expected to have this behavior - and would not be expected to run anything in the UI. So it would send messages, not display them.
It's ALSO possible that this is nefarious code. That's possible. Pocket dialing while it the screen is supposed to be locked is also possible.
I can send several thousand SMS messages this month and it wont cost me a penny.
Each MMS message will cost me 50p. Automatically sending all the images from my phone via MMS to even a single recipient would cost me a three digit sum.
I can imagine for some people you could add a digit with ease.
A good reason for not keeping all your pictures on your phone.
I download all mine to local storage every couple of months or so and then clean out the phone. One, it frees up phone memory and two, if the phone gets lost or stolen, there's less for the finder to use against me.
Indeed. However the phone doesn't differentiate between photographs I've taken and things like the book covers for the multiple ebooks I have on it.
Now I have an excuse for sending that pic to the hot chick in accounting. 'twasn't me, it was the phone! Drop that harassment suit already, dammit!
Besides, that's not a bathing suit. It's a tan line.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
It's amazed me that it's called "Agile" when it's the MOST rigid and inflexible process from the developer point of view. The schedule is not allowed to slip by even a single day, ever.
Imagine getting your hair cut. Everything is going well, great haircut, then at the last minute, when she's doing the edges and finishing touches free hand with those electric clippers, you yell "QUICK!!! HURRY UP!!!!1!!!!"
That's like the last day of a sprint. Rush through those last critical details so you can make the sprint demo. Because if you don't, you might as well have not come to work for the last two weeks.
The sprint is suppose to let shit slide to the next sprint. That's the whole point of regular mini-releases.
That doesn't help with hard endpoint feature demands by customers, but that's longer-term whole project planning.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
at the dawn of the consumer digital age: a world in which combines unprecedented convenience with unprecedented complexity and unpredictability.
For every prior generation convenience, simplicity and predictability were effectively synonymous.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
I can send several thousand SMS messages this month and it wont cost me a penny.
Each MMS message will cost me 50p. Automatically sending all the images from my phone via MMS to even a single recipient would cost me a three digit sum.
I can imagine for some people you could add a digit with ease.
Cool, so how do you send an image via SMS and not MMS?
I browse on +1 so AC's need not respond, I won't see it.
My point.
deleting the extra space after periods so i can stay relevant, yeah.
It's not the release schedule that's Agile, its' the development process...
Deployment to production is the last step of an Agile sprint. Otherwise you're doing Agile halfassed.
> Right so we should neuter everything we use to build the major bits of infrastructure in the world because newbies?
What we should do is not pretend it's any safer than Python, JavaScript, Perl, etc. Most languages don't have the problems that Rust fanbois gloat about. As I said, 99% of all security issues are unrelated to anything Rust does any better, so to pretend that Rust will solve your security problems, or even a significant percentage of security problems, is dishonest.
As a Samsung owner I am super excited about this feature. This will save me the time and money required to get blackout drunk and do this myself.
Samsung has become a toxic cesspool in technical division- Korean counterparts try to steal good projects from engineers abroad and try to sell it as their own. They track with hawk's eye on who is doing what. As soon as they see if there's anything special going on, they swoop and try to snatch it.
Another set of issue is dominance- Learning department and security depart dominate over engineers. Engineers' belongings are checked when they are leaving, and not when they enter the building. If anything is found, engineers are humiliated and blamed as if they were "stealing" anything. Learning department imposes yearly coding tests, and people are given dedicated time for weeks to compete through that.
All these issues together drove away the cream of the engineers, resulting in the politicking ones staying in, and the quality of software going downhill.
Base 64 encoding? I haven't tried.
Did you even read this thread before commenting?
I browse on +1 so AC's need not respond, I won't see it.
Why yes, yes I did. You were nonsensically comparing SMS and MMS costs, and although it would be a pain in the arse, it's significantly cheaper to use SMS.
Of course, slipping to another sprint is actually not deploying, so the last step is sometimes just a sprint away...
Though around here we see sprints complete, release to production, but of course the 'release' is actually part of the intended release. Parsing the meaning of 'release' is a sport on my team. I'm too optimistic, and usually lose the bet.
deleting the extra space after periods so i can stay relevant, yeah.
LOL so apparently you didn't read it.
I browse on +1 so AC's need not respond, I won't see it.
You're arguing three silly points. The first is more or less "someone on a forum said something I don't like therefore Rust is crap". Secondly, you're ignoring that the main aim of Rust is the same space as C and C++. And thirdly, you're arguing that all CVEs are equal.
The thing is, most infrastructure is built in C and C++. If there's a CVE in Chrome, it affects 58% of internet users. If there's a CVE in OpenSSL, it affects an *awful* lot of services. Remember heartbleed?
What we should do is not pretend it's any safer than Python, JavaScript, Perl, etc.
Firstly it's irrelevant because no one would write a major web browser in any of those. Remember what Rust if for, and remember how many people a CVE in a web browser affects?
As I said, 99% of all security issues are unrelated to anything Rust does any better
Yes you keep saying it but it doesn't make your point any more accurate. None of those supposed other languages you keep harping on about compete with C++. It doesn't matter how safe a Haskell based browser would be it it takes 10 minutes to render a web page.
so to pretend that Rust will solve your security problems
Stop denying that a lot of infrastructure is in C and C++ and that those languagea are not safe.
or even a significant percentage of security problems, is dishonest.
Eh I mean how important was heartbleed anyway? I mean that hardly affected anyone, nulike that CVE against that obscure wordpress plugin that affected positively 10s of sites...
SJW n. One who posts facts.
You keep talking about web browsers, pointing out that most of them have some C++ code. Is the point you're trying to make "if you're writing a new web browser, consider Rust for the C-ish parts?"
If that's what you're saying, fine, I won't disagree with that.
If someone is building a new web browser, of course they'll use XUL or similar where appropriate, and it makes sense to consider Rust for other parts. (I didn't say use Rust, but considering it as one option is fine.)
> The first is more or less "someone on a forum said something I don't like therefore Rust is crap".
Not quite. Most of the comments and questions about Rust, here on Slashdot and many other places, either state or assume that using Rust will magically make your software much safer than other languages. That's false. To tell people they are safe (and therefore need not be very careful) when they aren't is not only a lie, is intentionally putting people in danger.
You mentioned Heartbleed. Heartbleed was an input validation error - as in the input wasn't validated at all. If you use invalidated network input for cryptography you have a major bug. That's in no way language specific. Heartbleed written in Rust is still Heartbleed.
In Rust the function would be called std::ptr::copy_nonoverlapping instead of memcpy - it does the same thing, dump random memory back to the attacker. (Slice clone was not available at the time).
> And thirdly, you're arguing that all CVEs are equal.
I didn't say that. I said I study vulnerabilities for a living, full time, and for the last several darn few of them have anything to do with anything Rust would help with. Have a look at the OWASP Top 10 - the most significant types of vulnerabilities that happen nowadays. See how many of the ten are addressed by Rust. Spoiler alert - the number is zero. Rust helps with none of the classes of vulnerabilities that cause the most problems.
Had Rust come out, with a stable, fully usable version, in 1985 it might have been useful in the age of buffer overflows. As it is, Rust promises that in 2020 it solve a few of the things that were a problem in 1990.
Is the point you're trying to make "if you're writing a new web browser, consider Rust for the C-ish parts?"
That's literally what Rust was created for.
If someone is building a new web browser, of course they'll use XUL
You what? Firefox abandoned XUL.
and it makes sense to consider Rust for other parts.
Tha that is precisely what Mozilla is doing right now. They're slowly replacing C++ bit with Rust bits.
Not quite. Most of the comments and questions about Rust, here on Slashdot and many other places, either state or assume that using Rust will magically make your software much safer than other languages.
I think you're wildly exaggerating there.
You mentioned Heartbleed. Heartbleed was an input validation error - as in the input wasn't validated at all.
It was a buffer overflow overflow error triggered by lack of input validation. But if it had been in a memory safe language it would have been a simple DOS attack, not the single biggest security issue of the year.
That's in no way language specific.
Yes it is. How the fuck would heartbleed have allowd you to extract someone else's keys in Python, Java, Haskell, Rust..., well anything other than C or C++? It says here in the CVE that it's a buffer over-read (TIL there was a different term for read vs write in this context):
https://cve.mitre.org/cgi-bin/...
That would not happen in not C or not C++, because other language you know, check bounds and do other things.
Which brings us on to the other topic. Why do people write major bits of infrastructure like SSL libraries and web browsers in unsafe languages like C and C++?
In Rust the function would be called std::ptr::copy_nonoverlapping instead of memcpy - it does the same thing, dump random memory back to the attacker.
Well done! You picked an unsafe function. You can get the same effect in, say, python or Java by using a C module and scribbling all over memory too. Kinf od the point is to stick to safe code. And it's auditable.
The fact you can manage unsafe things in just about any language no matter how hard you try does not mean that C is very unsafe by default and that C++ has quite a number of cases where it's eay to foul up. It's much harder.
Make no mistake: if you manage to do something memory unsafe in Rust you have either subverted it (by explicitly doing unsafe things) or have found a genuine bug.
I didn't say that.
I didn't say you said that, I said you are arguing that. And you are because you kept repeating the point about the number of CVEs only while not taking into account their performance.
I said I study vulnerabilities for a living, full time, and for the last several darn few of them have anything to do with anything Rust would help with.
You seem to think that anything other than C or C++ would not have prevented heartbleed either. I don't know how you can study these things full time not know that. Other languages crash or throw exceptions when overstepping the end of an array. C and C++ don't.
Have a look at the OWASP Top 10 - the most significant types of vulnerabilities that happen nowadays.
That's great and still doesn't invalidate anything I said. Sure you're more likely to make your web application insecure with an injection bug. But if you get a CVE in Chrome, half of everyone on the intire internet is vulnerable in one go.
You seem to be intentionally ignoring the distinction between infrastructure and applications. Rust is and always has been aimed at the same space as C++ (and C[*]). The claim that Rust magically makes your code safe against things inrelated to C++ specifically seems to have been invented by you.
It's possibly you've simply misunderstood people: when people talk about rust being "safe" it's almost always in the context of memry safety and in c
SJW n. One who posts facts.
MMS is not SMS. You can tell by looking at the first letters.
It's quite close though!
To have a right to do a thing is not at all the same as to be right in doing it