5 ms·
>"Sunbird actually logged and stored messages in plain text on both the error reporting software Sentry and in a Firebase store. Authentication tokens were sent
by FirmwareBurner 3y ago
>"Sunbird actually logged and stored messages in plain text on both the error reporting software Sentry and in a Firebase store. Authentication tokens were sent over unencrypted HTTP so this token could be intercepted and used to read your messages"
Which product manager in his/her right mind, thought this was passable when you're building and marketing your product as an iMessage alternative and every single early access reviewer raised these exact security concerns in public?
It's the one thing you had to make sure was air-tight, especially considering the raised eyebrows and extra scrutiny you'll get from security researchers when they see something as juicy as "iMessage on Android". Any security issue on launch day/week will get you nailed to the cross and bury your credibility for good.
How do these managers get jobs in these big name companies? You could have at least hired a third party for a pen-test/security audit before the big launch. It's the best way to uncover shoddy dev and security practices that creep in when you're crunching to get something out the door by launch day.
- cnity 3y ago[flagged]
- mock-possum 3y agoIt really does beggar belief. I’d love to do interviews with the team, I’ll bet somebody knows why this happened, even if they’re not eager to talk about it.
- Zetobal 3y agoI call it one pm (who will tell you that he can totally code) at the offshore party.
- jwestbury 3y ago> Which product manager in his/her right mind, thought this was passable when you're building and marketing your product as an iMessage alternative and every single early access reviewer raised these exact security concerns in public? Why are we blaming PMs, here? Plenty of engineers out there make really stupid decisions every day. (To be clear: I'm an engineer, not a PM.)
- FirmwareBurner 3y ago>Why are we blaming PMs, here? Plenty of engineers out there make really stupid decisions every day. EXACTLY! Because it's a known fact all devs make mistakes, and as such, as a product manager/owner you're responsible for the bigger picture of the product and ensuring the right requirements, checks and bound are put in palce and validated for a successful product release. It's not the job of the lowly SW engineers who have little visibility in the product as a whole and who just sprint to punch out Jira tickets handed to them from above, to check your product works as intended, it's your job as a PM/PO to ensure the work of all the devs integrates nicely into a cohesive product as per the requirements/vision. Kind of like that famous story of that intern who got fired for deleting the production DB by mistake on his first day. Was it the intern's fault for the mistake or the fault of all the seniors and managers who should have placed the proper checks and bounds in place so that nobody can so easily delete the production DB? So the buck for the product success/fail stops with those at the top who orchestrate the band, not with the individual SW engineers at the bottom.
- mcny 3y agoJust yesterday I was protesting unnecessary complexity in my story until my lead had a sidebar chat about an upcoming project. How was I supposed to know that?
- sgarland 3y agoI hope this is facetious. Security is everyone’s job, and unencrypted customer data, outside of a locked-down DB, should give one pause.
- soulofmischief 3y agoEveryone here is to blame. Not just the PM, not just the engineers. I'd also blame the hiring manager.
- kergonath 3y agoAll the way to the CEOs. I find it hard to believe that someone at this position in a tech company did not see any red flags, particularly as all the tech forums I have seen pointed out the potential issues within minutes of the announcement.
- nikanj 3y agoThe product manager was overridden by the board / CEO who emphasized hyperaccurate metrics and time to market. Product managers are usually caught in the crossfire between a dev team who can't left-pad without 400 packages, and a C-suite who does not give a flying french fry about technical details.
- ingenieros 3y ago> How do these managers get jobs in these big name companies? Nothing is very far from what I would consider a "big name company" They are actually a really small joint venture between Carl Pei and Teenage Engineering. This whole iMessage fiasco is exactly why I have such a hard time taking Carl seriously in anything he does. He seems more concerned with creating hype through smoke and mirrors than in releasing anything truly innovative and substantial.
- FirmwareBurner 3y ago> They are actually a really small joint venture between Carl Pei and Teenage Engineering. That's just 'Nothing' the company making the phone, but the iMessage for Android app was built by Sunbird, a different company. It's written in the article. Agree that these companies are more like Juicero, built on hype and false trust to sell mediocre products that aren't special.
- hug 3y agoIs Teenage Engineering actually a part of a joint venture or are they just design consultants used to pump brand appeal?
- ingenieros 3y agoAccording to this old article they are much more than simple consultants: https://www.theverge.com/2021/2/24/22298802/nothing-teenage-engineering-swedish-design-founding-partner-audio-headphones https://www.theverge.com/2021/2/24/22298802/nothing-teenage-... "Pei says that Teenage Engineering is one of Nothing’s founding partners, and will drive the design aesthetic at his new company."
- rchaud 3y agoUp until now I had no idea TE had anything to do with Nothing phones.
- Lacerda69 3y agoI like their mini synths. Never knew that they are involved with phones or anything beyond small synths tbh.
- donkeyd 3y agoI work for a company like this right now. About the same number of employees, same mistakes and same time to market on innovative stuff. Here's my two cents on how this can happen: > Which product manager in his/her right mind There is no product manager. There is a project manager. They steer on deadlines and functionality, nothing more. > How do these managers get jobs in these big name companies? Because they talk well and they've delivered before. Have they delivered something good and secure? Nobody cares, deadlines were met and functionality was shipped. I notice the same in IT sales. Sell too much for too little, collect bonus and move on. Nobody comes back to you if the project fails or becomes too expensive and if they do, you blame the one engineer you had glance over the proposal before sending it to the client. > It's the best way to uncover shoddy dev and security practices As a project manager, that's the last thing you want. First, it'll show what you didn't manage well. Secondly, it costs money. Finally, negative findings will delay delivery and means you failed to deliver on time, which is your only priority. Maybe I sound overly cynical, but I've seen this exact thing happen everywhere, from small firms to Fortune 500 to government.
- FirmwareBurner 3y ago>As a project manager, that's the last thing you want. First, it'll show what you didn't manage well. Secondly, it costs money. Finally, negative findings will delay delivery and means you failed to deliver on time, which is your only priority. And yet FAANGMAULs and other tech-first companies like Mozilla, seem to be doing quite well on security with relatively very few oversights, caused by dev gross negligence. So it's definetly possible to deliver airtight products if that's your goal and part of your dev culture, instead of just "ship it by Christmas at any cost".
- Schiendelman 3y agoSure, they have product managers.
- ziddoap 3y agoIt's too early to play guess the acronym for me. What is the MAUL part of your FAANGMAUL acronym.
- htrp 3y agoProject managers are often confused for product managers
- lawgimenez 3y agoAs a security researcher, bad security practices are prevalent in mobile by big companies and governments alike. They are just hoping that no one will reverse engineer their apps and APIs.
- fredgrott 3y agowhat damn engineer thought it was good idea to have sentry on in release on an app that uses firestore? I am extremely careful of when I turn on release app mode reporting to 3rd parties and about sandboxing said things so that passwords and ug messages do not get sent to 3rd party.
- Kalium 3y agoThis has the overall feeling of something developed by a team where leadership sincerely believes that security is everyone's job. Because it's everyone's job and they hire good people, they don't need specialists. When there are deadlines to hit, average quality non-specialist management will generally prioritize keeping promises to leadership over meeting security requirements. It takes a rare manager with a strong grasp of the importance of security to stand up and tell their VP "We're not shipping, the security isn't there". So how do these managers get there? They cut the corners that don't matter and hit the ship date. It gets them the promotion.
- sbehere 3y agoReplace 'Security' with 'Safety' and your comment still rings eerily true! One exception (? probably not an exception) is that sometimes organizations will still hire safety/security specialists (because the externally viewed perception of not having them is damaging), but these specialists are then (perhaps unintentionally) knee-capped to various extents in order to prioritize promises to leadership or other org. goals that must be hit. The net result is that good and capable folks who care deeply about the company's mission may watch in consternation as the org. slowly train wrecks itself if the roll of the dice doesn't land right. See, for example, the story of several autonomous driving organizations.
- grumple 3y agoThis is shockingly bad. Like so bad it has to be malice, right? To make requests over HTTP instead of HTTPS you have to do so intentionally, right? > Which product manager in his/her right mind, thought this was passable when you're building and marketing your product as an iMessage alternative and every single early access reviewer raised these exact security concerns in public? This all falls on technical leadership and the software engineers. No passing the buck to non-technical people who aren't reading or writing code and probably don't understand encryption (although they should at a place like this).