[HN Gopher] Ask HN: Twilio suspended account because someone sen...
___________________________________________________________________
Ask HN: Twilio suspended account because someone sent us a fraud
text
I have a very weird problem with Twilio. It seems like they have
gotten so big where they have started acting in bad faith. I'm
curious to find out what other entrepreneurs think of this
situation, where a partner, once trusted, and for which technical
foundation has been built upon, now has shown to be acting in bad
faith. Every once in a while, some scammer will send a phishing
text message to one of our phone numbers. Here is an example: """
Your Facebook account has been placed on hold for verification. To
avoid account suspension, Please visit: https://opensopstat.com/
""" The message will be relayed to en employees cell phone as is
what happens with all txt messages. Now Twilio thinks our account
was hacked and someone is sending text phishing text messages from
it. The latest time this happened, the account was immediately
suspended by an automated system. They did not communicate to us
that this happened or why it happened. I had to fill out a support
ticket and wait about 3 hours for a response before I even knew
what the problem when was. This happened at night, so no one knew
there was even a problem until the next morning when business
operations resumed and the phones didn't work. Its bad enough that
they shut down the phone system for my entire company because of
their mistake, but in order to get the system back online, I have
to go through their ticketing process that is only through e-mail,
where it takes hours or days to receive a response. If I want to
speak with someone on the phone, which probably would have gotten
the problem resolved more immediately, I have to pay $1,500 per
month for their phone tech support. Obviously this is an
unreasonable amount to pay. I don't need tech support, I just need
someone to call, explain the situation to, and have them click a
button. We pay them about $600 a month and have been working with
them for over 10 years. I understand their profit margins might be
thin? But are they really that thin? And if so, there should be a
more reasonable phone option. I don't need to speak with an
engineer, I just need to speak with someone who can click a button
and unblock the account. Temporarily, I will re-program the system
so that it does not forward text message content to my employees
phone numbers. Which is fine. But my bigger problem is what do I do
now? If they're willing to shut my system down without even giving
me a number to call, what else are they going to do to me in the
future? The way in which they have been so cavalier with me is a
red flag. And if I'm being honest, it does make me angry how they
are willing to so readily damage my company in such a profound way
AUTOMATICALLY without giving me a way to talk with them. I
understand they may have a big phishing problem and will need to
use automated software to help, but it is very reckless to not have
this counter-balanced with a reasonable way for legitimate
customers to even contact them after the suspension. Are there
other API-driven VOIP options that I should be considering bearing
in mind that it would be expensive to re-write the software to work
with another vendor? Or is there some way I should be looking to
work things out with them? What do you guys think?
Author : ChrisDutrow
Score : 129 points
Date : 2022-01-06 17:38 UTC (5 hours ago)
| daneel_w wrote:
| It's been a year or two since Twilio became so large that the
| left hand has no idea what the right hand is doing. You have my
| sympathies. Good luck.
| SN76477 wrote:
| They were also a nightmare for us. We had to find another
| provider.
| csdvrx wrote:
| Could you recommand one that provies SIP trunking and number
| porting?
| icedchai wrote:
| I'd look at SignalWire. It's way cheaper than Twilio and they use
| the same APIs.
| bryanrasmussen wrote:
| I am confused by one thing - when you forward to your employee's
| phone number is that number also owned by your company? Or is it
| a phone number owned by the employee.
|
| If the first Twilio should fix this bug in their system, if the
| second then they should maybe have some process of setting up
| employee phone numbers in their system so the shut down process
| does not happen. At any rate both scenarios should be common
| enough that they should have a process to handle that.
| tonightstoast wrote:
| Sorry you're going through this. At my last company we were in a
| similar spot to you - around ~$700/mo spending for Twilio. We had
| issues where they also were shutting us off and were unresponsive
| for days at a time. Once we had a rollout with a few dozen new
| clients in an area where we hadn't sent texts before and after
| sending a few thousand messages we were shut off at the carrier
| level. We tried reaching out for a day or two and really didn't
| get much back in response - to us this was the final straw and we
| moved to bandwidth.com (which I believe is who google uses for
| their auth).
|
| Support with them is significantly better but if I remember
| correctly pricing is around $1k/mo minimum (which was more than
| worth it in our case).
|
| Best of luck to you.
| ChrisDutrow wrote:
| UPDATE:::::
|
| Due to Greg from Twilio seeing this post and providing me a way
| to reach out, I was able to get the problem resolved.
|
| He spent about an hour on the phone with me today and provided
| some more information about the issue. A few highlights:
|
| * Twilio has doubled in size since the beginning of the pandemic
| * Spamming and phishing through text message has gotten a lot
| more common very recently.
|
| These two things together caused a sort of novel situation with
| them having to either auto-ban accounts of ban accounts with only
| a very shallow look and then not having a way for someone to get
| the account un-banned in a timely manner.
|
| My initial concern with this post was that something had changed
| within the company culture where they were willing to cull off
| "smaller" accounts like mine in the $10,000 a year range by
| treating them very recklessly so that they only needed to work
| with very large companies which would be more simple and more
| profitable. This would mean that I would need to change providers
| or risk them doing other damaging things in the future that I
| would not be able to predict.
|
| Based on a few things that Greg said in the conversation, I no
| longer believe this to be the case for a few reasons:
|
| 1) They have people like Greg reaching out to people like me at
| all. 2) In case Greg was not available the next time something
| like this happened, he provided me the contact information of
| some other people who were kind of high up in the company and
| explained that they would be very concerned that something like
| this was going on where legitimate customer accounts were being
| suspended.
|
| This changed my interpretation of the situation because Greg's
| actions communicated to me that this is a temporary problem
| having to do with Twilio increasing in size very quickly at the
| same time spam and phishing became a big problem. They had to
| scramble to fix a problem with their providers before having a
| chance to refine their systems to make sure the implementation
| was done fairly and correctly. It does not seem to be a problem
| with top-level executives deciding that customers like me don't
| matter.
|
| I also own a company and am very familiar with how things can get
| out of hand very quickly when demand increases. Shit hits the
| fan, then things suck for a while until the work is put in to
| become more organized. This takes time. And it takes trial and
| error.
|
| I would expect over time for them to correct their systems and
| properly service smaller mid-range customers like me.
| paxys wrote:
| Why misdirect from the real issue just to rally an internet mob
| in your favor? The problem clearly isn't that you received a
| fraud text (as the title suggests), it is that you SENT fraud
| texts using Twilio. That will obviously get you banned from any
| mainstream service.
|
| Also:
|
| > I don't need tech support, I just need someone to call, explain
| the situation to, and have them click a button.
|
| What do you think tech support is?
| nickphx wrote:
| It sounds like you relayed a message that contained abusive
| content. To twilio it looked like your account was sending
| abusive content and they acted according to agreements with
| carriers to prevent abuse. Don't relay abusive content and you
| won't have this problem.
| throwaway2127 wrote:
| howdydoo wrote:
| Auto-banning an account is a violation of GDPR Article 22
|
| https://gdpr-info.eu/art-22-gdpr/
|
| > The data subject shall have the right not to be subject to a
| decision based solely on automated processing, including
| profiling, which produces legal effects concerning him or her or
| similarly significantly affects him or her.
|
| Quote this and maybe it will get you escalated, but who knows? A
| lot of companies seem to just ignore GDPR entirely.
| PeterisP wrote:
| This is absolutely not applicable even if both parties were in
| the EU, a company can not be a data subject under GDPR (only
| "natural persons" are), any GDPR clauses about automated
| decisions (and others) protect only individuals and not B2B
| accounts.
| teh_klev wrote:
| GDPR can only be enforced for citizens in the EU/EEA and (for
| now) the UK. I think the OP is based in the US as is Twilio.
| tzs wrote:
| Nitpick: The GDPR says it applies to persons who are "in the
| Union", which seems it would cover non-citizens who reside in
| (or are even just visiting) the EU, and would not cover EU
| citizens who are not in the Union.
| teh_klev wrote:
| Yeah, re-reading I should have used "persons" rather than
| "citizens"; was playing a fast and loose with the meaning
| of "citizen" and didn't actually mean a "citizen of".
| ChrisDutrow wrote:
| Thats right, we're in the US
| ranma4703 wrote:
| Paragraph 1 shall not apply if the decision: is necessary for
| entering into, or performance of, a contract between the data
| subject and a data controller; is authorised by Union or Member
| State law to which the controller is subject and which also
| lays down suitable measures to safeguard the data subject's
| rights and freedoms and legitimate interests; or is based on
| the data subject's explicit consent.
|
| If you send abusive texts through Twilio, Twilio could lose
| it's contracts with carriers. I haven't read through the
| paperwork Twilio makes you sign, but I'm gonna guess the fact
| that this could happen is in there. Also it sounds like the
| account wasn't banned, it's ability to send messages was
| suspended. Because it was being used to send spam text
| messages. I'm pretty thankful Twilio has automated systems for
| that
| themerone wrote:
| > I don't need tech support, I just need someone to call, explain
| the situation to, and have them click a button.
|
| What you are describing is tech support.
| ejb999 wrote:
| >>What you are describing is tech support.
|
| No that is customer support - big difference.
| [deleted]
| gregorymichael wrote:
| Hey Chris, Greg from Twilio here. I'm so sorry for the
| frustration, lack of communication, and high friction to get this
| resolved. Want to drop me an email at gb@twilio.com and we'll see
| if we can get it sorted out?
| andrei_says_ wrote:
| Greg, it would be very useful if you could recommend a setup
| which would allow forwarding sms to employee numbers without
| the risk of account suspension.
|
| Many of us use twilio and an account suspension is an
| undesirable scenario.
|
| "Forward unless spam/problematic" would be very nice.
| ChrisDutrow wrote:
| I just talked to Greg, he said something that might help
| would be to add "FWD: " before the forwarded message. Or
| possibly "Forwarded from XXX.XXX.XXXX: "
|
| I can confirm that my system did forward the message without
| any modifications at all. (my employee knew what it was
| because he knows all text messages from that number are
| forwards)
| yodon wrote:
| This sounds like a highly problematic solution. If twilio
| actually greenlights spam that starts with "Forwarded from
| XXX.XXX.XXXX:" as Greg suggests, you can be sure actual
| spammers reading this thread will catch on and start
| sending spam texts with a header intro like that, probably
| by EOD today.
| ChrisDutrow wrote:
| I think one of the key contexts here is being forgotten:
|
| These are all internal messages. Someone cannot use our
| system to text random people. It's literally one person
| seeing them. We're a local service company. We're not
| SAAS or something like that. It's just people messaging
| us "Hey can you guys come Thursday?"
|
| This would be like if you signed up for a VOIP provider
| for your business phones and they suspended your account
| because someone sent you a phishing text message.
| DyslexicAtheist wrote:
| hopefully you can find a way to solve this. Sounds like all
| somebody needs to take a business offline is the knowledge that
| they are using twillo (easy) and that they're forwarding texts
| to employees.
| ChrisDutrow wrote:
| Ok I just e-mailed you, thanks so much
| _hyn3 wrote:
| When a company has gotten so automated that the only way to
| get a solution is to beg and plead for help about it on
| social media, it's too automated.
| helloworld11 wrote:
| The fact that this particular customer was only able to get a
| "friendly" human resolution for this by first posting about his
| problem on a tech-heavy social media platform like HN speaks
| very poorly about your company's customer service. I know that
| the giants like Google, Facebook et al shit all over their
| users now that they're large, but it would be nice to believe
| that it hasn't turned into a fad even among smaller companies
| doing it against their fully paying clients. Shameful.
| desmosxxx wrote:
| Even employees of those companies can't get help when they
| need it. I've seen a case where an employee's account was
| incorrectly banned (or well that was their assumption) and
| they still couldn't get through to any of the teams.
|
| It's getting pretty rediculous
| [deleted]
| fatnoah wrote:
| > Temporarily, I will re-program the system so that it does not
| forward text message content to my employees phone numbers.
|
| I might be reading this wrong, but it sounds like you take
| inbound text messages to one number and then send outbound
| messages with the same content to employee phone numbers. Is that
| right? If so, that sounds like you're SENDING the spam messages
| in addition to receiving them. Regardless, it sounds like
| customer service needs to be improved, though.
| ChrisDutrow wrote:
| This is not quite right. We aren't sending the messaged from
| the original number. As far as I know, that isn't really
| possible because we don't "own" that original number.
|
| The business case of relaying inbound text messages to an
| employee's phone number should be a very common one and should
| not warrant an account suspension.
| jlundberg wrote:
| This is actually technically possible in the networks, at
| least here in Europe (generally).
|
| However, obviously allowing such sms forwarding have to be
| done with care.
| YXNjaGVyZWdlbgo wrote:
| The fact is that you are sending spam over twilios network
| even if it's just to your own employees. You are also saying
| it is not the first time it happens and you seem to have done
| noting to mitigate the problem at hand furthermore is it an
| attack vector for phishing against your company. The fact
| that you are not ingesting the text into another system is
| also a bit concerning how do you handle GDPR requests? If you
| are looking at the problem objectively twilio is in the
| right.
| Turing_Machine wrote:
| Here's what's happening, as I see it (corrections welcome):
|
| 1) Spammer sends spam to customer's Twilio number. 2)
| Customer has this number set up to forward incoming texts
| to employees. 3) Customer has no available API to detect
| whether texts are spam. 4) Twilio apparently _can_ detect
| that this message is spam, but rather than simply dropping
| it at step 1, they 're blaming the customer.
|
| Sorry, there is no scenario under which this is the
| customer's fault.
| YXNjaGVyZWdlbgo wrote:
| You are suggesting that a service that has no idea of
| what your business is should curate your data and "simply
| drop it"? yikes.
| Turing_Machine wrote:
| Umm... "curating the data" is exactly what they're doing
| when they ban the customer for forwarding spam that
| originated from their system.
| mbreese wrote:
| The are otherwise curating the data and calling it spam
| on the outbound, so... yes?
| YXNjaGVyZWdlbgo wrote:
| Because they have made it pretty clear in their ToS that
| it is forbidden to send any form of spam over their
| network.
| eropple wrote:
| They're receiving the spam because it's sent to the
| customer.
|
| They're sending spam when the customer asks.
|
| They're also deciding that that customer is a customer no
| longer because of the choices that customer made with
| regards to sending spam, not receiving spam.
|
| These are pretty different things.
| ejb999 wrote:
| >>You are suggesting that a service that has no idea of
| what your business is should curate your data and "simply
| drop it"? yikes.
|
| As opposed to just shutting down the customer because
| TWILIO forwarded the spam, that we already know that it
| can detect?
| YXNjaGVyZWdlbgo wrote:
| If you have a business that deals with spam texts or if
| you host a honeypot for whatever reason you are allowed
| to do it. You are allowed to receive spam and do whatever
| you want with it except sending spam over twilio itself
| because it's against their ToS and to protect their own
| core business from getting their numbers blacklisted.
| em-bee wrote:
| if twilio can not differentiate between inbound messages
| that are being forwarded and outbound messages that are
| created by the twilio customer then their service can't
| guarantee to be reliable because someone could basically
| create a DOS attack by sending spam to any twilio
| customer expecting that twilio will blame their customer
| and suspend the account.
| YXNjaGVyZWdlbgo wrote:
| It's not their job to differentiate they are just a
| carrier they scan for outgoing spam to protect their own
| core business and to not get blacklisted everywhere. Read
| the ToS they are pretty specific about it.
| em-bee wrote:
| but then they are simply not suitable for the use case of
| forwarding inbound messages because the risk is to great
| that i'll get shut down just because i am receiving spam.
| YXNjaGVyZWdlbgo wrote:
| Yes.
| ohyeshedid wrote:
| ...or the complaints that caused the account suspension
| didn't come from Twilio. More than likely, the employee
| cell carrier noticed the spam and sent an automated
| complaint to Twilio, and then Twilio acted.
|
| That doesn't excuse poor support, and the lack of
| resolution, but it changes a lot of the assumed
| processes.
| ChrisDutrow wrote:
| I did mitigate the problem last time. I communicated with
| them and they told me it was fine.
|
| I'm very curious. Is this a communication mistake? Like do
| you think I'm some big company that forwards text messages
| to random people?
|
| Do you understand these are text messages being sent to one
| of like 3 employees at my small company? We are not
| generating outbound content or allowing anyone else to do
| so. Your question about GDPR requests makes me think maybe
| you have misunderstood the context.
|
| If you have correctly understood the context, do you
| actually think I should have some kind of AI algorithm
| scanning these messages for Phishing?
|
| I'm not sure I understand what your are suggesting or how
| you would have solved this problem? You would have just
| turned off the text message forwarding I guess?
|
| Is that how you solve problems? You see a problem, then you
| destroy the thing that caused the problem, so problem
| solved? What do you do for a living with that type of
| cognitive approach? Are you an entrepreneur? Do you really
| run a business with that attitude? Are you en engineer? If
| so, when you are asked to make something work, do you just
| tell your boss "no" if you run into a problem that requires
| a creative solution? Are you a lawyer? Is your job to tell
| people what thing they cannot do, but not to help people do
| new things? That would kind of make sense...
| YXNjaGVyZWdlbgo wrote:
| It's not even good business practice you are paying for
| something that is essentially free if implemented in
| every other way. This is not creative this abusing a
| system going against their ToS and blaming them for your
| own failure. I am suggesting you ingest the received
| messages and distribute it any other way like a lot of
| twilio customers probably do. This is merely a hack and a
| bad one at that.
| ChrisDutrow wrote:
| I'm still curious what you do for a living. You seem like
| you would be good a good lawyer or accountant. Something
| that involves rules and safety. A lot of the things you
| say would be correct without accounting for the
| complexity of actual reality.
|
| The reason I ask is because I see a lot of posts of this
| nature from lots of people in lots of contexts. Sort of
| like seeking safety in rules. I'm always curious what
| niche this type of thought process applies successfully
| too.
| YXNjaGVyZWdlbgo wrote:
| Personal attacks aside you seem like a terrible person to
| do business with.
| soco wrote:
| And where are those people receiving the spam message in
| the first place? From Twilio's system right. If they are so
| good at detecting it circulating internally, why didn't
| they detect it and block it in the first place?
| DSMan195276 wrote:
| > From Twilio's system right.
|
| Do we know this? I don't think OP has clarified - they
| just said it goes to an "employee's phone number", which
| makes me assume it goes out to their personal phone
| number which is probably not on Twilio. If that's the
| case I'm wondering if Twilio received some kind of
| complaint from the employee's carrier that they forwarded
| the message too, rather than detected it themselves.
| YXNjaGVyZWdlbgo wrote:
| It is simply against the ToS to send spam over twilios
| network. Objectively this is what OP is doing. You are
| allowed to receive spam maybe your core business even
| depends on getting spam numbers or analyzes the spam for
| phishing links itself. You can receive and ingest it in
| anything you want you just can't send it over twilio
| yourself. Sorry this is not a design flaw this is just a
| bad workflow.
| mindslight wrote:
| > _Objectively this [send spam] is what OP is doing_
|
| No, no it is not. These are legitimate consentual
| messages, regardless of the content. Please stop applying
| mechanical interpretations of obtuse rules and pretending
| it's some profound wisdom. Twilio and the rest of Big
| Tech are already doing this enough, thank you.
|
| Ultimately I think this problem is the end game of
| companies finding ways to absolve themselves of any
| liability through contracts of adhesion. When there is no
| downside to harming 1% of your customers besides losing
| 1% of revenue, biasing for egregious false positives
| makes financial sense. Same thing with terrible customer
| service policies crafted around keeping costs down, that
| prevent easily correcting these terrible automated
| decisions. About the only thing one can do is signal
| boost so others stay the fuck away from services built on
| broken assumptions, hopefully turning that 1% into maybe
| 10% where it starts to hurt them and they're once again
| encouraged to do competent system design.
| _hyn3 wrote:
| This is absolutely a Twilio design flaw.
|
| It's an incredibly common use case to _forward_ text
| messages from one incoming line to another number that is
| controlled by your company, and it 's impossible to tell
| _at the point of receipt_ (when it 's still in Twilio's
| network) whether it's spam or not before forwarding it
| on.
|
| It's the same exact thing that you might do if you have a
| support@example.com email address; it probably sends
| incoming emails to a number of different inboxes, _even
| if_ those incoming emails are spam (and even if there
| actually is a spam system in place that might block some
| percentage of incoming messages, and Twilio doesn 't even
| provide that.)
| chucksmash wrote:
| > it's impossible to tell at the point of receipt (when
| it's still in Twilio's network) whether it's spam or not
| before forwarding it on.
|
| That OP mentioning "reprogramming the system so it
| doesn't forward messages" makes me think that they are
| receiving the incoming messages programmatically via
| webhook and then using Twilio API to send a new message
| with same text to new number (their employee).
|
| In such a case, they do have a point in the process where
| they can implement some kind of filtering or processing
| (maybe stripping or obfuscating URLs?)
| YXNjaGVyZWdlbgo wrote:
| Twilio is a carrier and nothing else by having zero
| tolerance against outgoing spam they are protecting their
| own core business. If OP or you in that regard would even
| glimpse at their ToS instead of just scrolling by when
| your business depends on it OP would not have made this
| user error.
| Sohcahtoa82 wrote:
| What they're getting at is that Twilio clearly already
| has the capability of automatically detecting spam.
|
| Why not open that capability to an API so that somebody
| who is operating some sort of forwarding service to run
| spam detection before forwarding?
| YXNjaGVyZWdlbgo wrote:
| Because they are not in the business of filtering spam
| they are in the business of receiving and delivering
| messages. The spam filtering outbound is to protect their
| own core service. Running spam protection for your own
| service is a lot different to offering spam protection
| for customers.
| chc wrote:
| If you're going to hold people responsible for meeting a
| metric, you need to ensure they have a way of measuring
| the thing in question. To do otherwise is unreasonable by
| definition. If Twilio's definition of "sending spam"
| matched the OP's, where it's about sending messages the
| user did not agree to receive, then that would be
| reasonable. But instead it's something more intangible.
|
| And like you say, they do need to prevent their system
| being used for sending spam. But if they're not going to
| provide a way for honest parties to avoid sending spam,
| they need to be reasonable about how they react to spam
| reports.
| ChrisDutrow wrote:
| Exactly. Also I should point out that we weren't sending
| spam. It's just relaying the messages that we receive
| internally.
|
| I would think sending spam would be more if we allowed
| people to sign up for a our service and then people used
| it to send spam.
|
| But these are all internal communications.
| [deleted]
| vorpalhex wrote:
| I have set up a few twilio accounts like this where a business
| number blindly forwards to the business owner's personal cell,
| maybe some logic for business hours and holidays.
|
| If twilio wants us to start filtering spam messages for these
| cases, they need to give us the API/tooling.
|
| Or let us pre-register receiving numbers through an opt-in
| process.
|
| I understand Twilio not wanting to be an open relay but the
| reported solution is not the way.
| ChrisDutrow wrote:
| Yes or they could have just blocked the messaged before it
| hit my system. They are the ones that originally allowed the
| message to get to me. Then when I process it, they suspend my
| account.
| Fatnino wrote:
| Perhaps your employee's cell carrier detected the message
| as spam and automatically complained to what it saw as the
| source (twillio). From twillio's point of view they
| absolutely and unequivocally need to keep the carriers
| happy. If Att or Vzw simply blocks all twillio then twillio
| is dead. When faced with the choice of losing the entire
| company or losing your $600 a month it's pretty obvious why
| twillio has in place the automated system you recently
| chafed under.
|
| It's probably a good idea for twillio to be more reachable
| to any paying customer, at least until a human employee
| makes the determination if the customer is a spammer.
| nikanj wrote:
| Rules for thee, not for me
| madars wrote:
| Yeah this sounds highly problematic. Maybe in the meantime
| you can text links to your own portal instead. I.e. "New SMS
| received from +123... . Read it at: https://your-internal-
| infrastructure.com/sms/[GUID]" (maybe with a simple login so
| Twilio auto-fetch, if any, gets a benign page). That way
| there is no spammer-controlled message content (apart from
| the phone #) in the message you send. Or convert them to jpeg
| and send as MMS hoping that Twilio won't OCR that :D
| ChrisDutrow wrote:
| Yes, these are very good ideas. Didn't even think of the
| JPEG one, very cool!
| jdavis703 wrote:
| If someone has already written a custom integration, how hard
| can it be to wire it up to a spam detection API? It sounds
| like the integration was sending spam (not intentionally of
| course), which none the less is a TOS violation.
|
| If they can't update the integration with spam filtering,
| then it seems like they should be using COTS software.
| ChrisDutrow wrote:
| I'm already using a spam detection API. But remember those
| things don't block all spam.
|
| Also, there are other ways to solve this specific problem
| given that they are intent on auto-suspending my account in
| this type of context. I could relay the messages using a
| different platform as an example.
|
| Thats not really the point though. Me not paying for the
| spam API or not using it when I relay messages internally
| to employees is not a good reason to shut my whole business
| down and not give me a way to contact them. This should be
| obvious.
| kamray23 wrote:
| It seems to effectively be forwarding the text messages, like
| an SMS mailing list. If Twilio can't deal with forwarding
| messages as they come in, no matter the content, it's their
| problem.
| onphonenow wrote:
| I'm actually very glad Twilio doesn't allow itself to be used
| for SMS spam. I hate SMS spam. Twilio doesn't know that these
| are "employees".
| boardwaalk wrote:
| Maybe they should know they are employees? i.e. allow an
| employee to register their number and require inputting a
| texted code to confirm? (I don't know if they do, not a
| customer.)
|
| This does seem like a very common use case that Twilio
| needs to not punish.
| onphonenow wrote:
| No, they aren't designed for this use case. Sending
| messages from third parties is always MUCH higher risk
| then sending your own messages.
|
| Same principal with money transfer. If you start
| accepting money from someone to transfer to another
| person that is MUCH MUCH higher risk - every bank /
| online payment player should be looking out for that and
| probably getting you into a different account type.
|
| Twilio is clear, they are designed for systems where you
| message folks.
| Xylakant wrote:
| Twilio could fairly easily verify that the phone number
| owner consents: when setting up the recipient number, allow
| for double opt in - send a verification code that must be
| entered somewhere.
| onphonenow wrote:
| Twilio does not allow a user to "consent" to receive
| spam.
|
| This is specifically covered in their ToS by the way.
|
| "We never allow some types of content on our platform,
| even if our customers get consent from recipients for
| that content."
|
| This is for the simple reason that a lot of folks are
| using Twilio for application to person / transaction
| messaging - and the key to delivery quality is to have no
| crap content going out.
|
| If you operate an open relay for email - your IP address
| is going to be blacklisted very quickly. Same here, if
| twilio allows spam and fishing to go out, deliverability
| is going to go way down. Down the chain people don't know
| folks have "opted in" to the facebook phishing emails.
|
| Sign up here for a code to win XXX. Then they send you
| the code (which is the twilio opt in code) and bam, you
| are in the spam list. All these things have happened on
| the email and other platforms side already.
| jjnoakes wrote:
| > If you operate an open relay for email - your IP
| address is going to be blacklisted very quickly. Same
| here
|
| This doesn't sound like an open relay (since the incoming
| message can't be forwarded to arbitrary destinations),
| this sounds like a mailing list. And if my mailing list
| was banned because someone else sent spam to it, I'd be
| upset too.
| onphonenow wrote:
| I'm making the point that sending messages on behalf of
| others DRAMATICALLY increases the risk that you will send
| low quality messages. Spam, phishing etc.
|
| I'm more surprised that folks don't get that.
|
| Twilio is clear. You are responsible for all messages you
| send using their platform. They are clear in their terms
| that this applies EVEN IF you allow others to use your
| service in ways that result in crap going out.
|
| They DO NOT want spam or phishing messages going out from
| their numbers.
|
| Everyone here saying this is "bad design", outrageous or
| whatever has not had to deal with spammers / scammers.
| This simple rule, you are responsible, full stop, for
| what you send using our API's, and if you send crap, we
| will suspend you - probably saves them from 90% of the
| abuse issues they would otherwise deal with.
|
| Downstream, T-mobile, verizon etc - they don't care that
| the message was "consented" to by someones supposed
| "employees". When their customer reports spam coming from
| one of these numbers and if that number is verified ->
| game over for twilio
| ihumanable wrote:
| I worked at Twilio for 6 years, the carriers would never
| allow the thing you are asking for.
|
| Twilio outbounds the SMS message over the carrier
| network. Part of that relationship is that Twilio has to
| prevent spam from entering the carrier network, or the
| carriers will ban the interconnect.
|
| Here's the full workflow of this situation.
|
| The inbound leg looks like this.
|
| [Spammer] -SMS-> [Carrier] -SMS-> [Twilio] -HTTP->
| [Customer]
|
| The outbound leg looks like this (the customer initiates
| this in response to the HTTP request)
|
| [Customer] -HTTP/TWIML-> [Twilio] -SMS (SPAM DETECTION
| HERE)-> [Carrier] -SMS-> [Employee]
|
| All of these parties are separate entities, each
| enforcing spam blocking. Twilio is incentivized to not
| transit spam over the Carrier because the Carrier will
| get upset at Twilio. Twilio has no way to tell the
| Carrier "Oh, hey, this is spam, but the customer owns the
| number and they said they were cool with getting spam,
| please don't get angry"
| Turing_Machine wrote:
| If Twilio can detect that it's spam, surely the correct
| procedure would be to block it when it first comes into
| Twilio's system from outside, not blindly forwarding it to
| a customer's list and then blaming the customer for it!
|
| Sorry, this is just bad design.
|
| Re: > The customer may want to handle / filter the spam.
|
| Then provide the customer with a "yes, send me all the
| spam" option.
|
| Which do you suppose is the common case here?
|
| 1) Customer doesn't want spam.
|
| 2) Customer is doing a "study of spam"
|
| 3) Customer is running a spam filtering service.
|
| Yeah, it's 1), dude, in a gigantic majority of the cases.
| onphonenow wrote:
| False. The customer may want to handle / filter the spam.
| The customer may be do a study of spam. The customer may
| be offering their customers a spam blocking service.
|
| Fine to provide an option to filter it perhaps, requiring
| twilio to block what it THINKS is spam is a recipe for
| disaster, spam filters are no where near perfect.
| [deleted]
| cjm42 wrote:
| They could at least provide an indication when delivering
| the spam that "Twilio believes this message is spam and
| will block your account if you try to resend it".
| jeremyjh wrote:
| > requiring twilio to block what it THINKS is spam is a
| recipe for disaster
|
| Yet they are disabling the entire account when they think
| it has sent spam.
| desmosxxx wrote:
| provide an option? send spam to some other bucket that
| the customer can view? label it so customer can filter
| it? warn them / block outbound spam (if it's not high qps
| I dont see a reason for the zero tolerance here, some
| kind of restricted mode is more reasonable). Communicate
| with the customer, especially when they contact you..
|
| So many other options here
| rsync wrote:
| "If so, that sounds like you're SENDING the spam messages in
| addition to receiving them."
|
| This is a bizarre and almost intentionally obtuse
| interpretation of the ops problem (albeit literally correct).
|
| If I have built an auto-forward between two endpoints that I
| control (or at least have permission or authority over) I am
| _not a bad actor in any capacity_.
|
| A _much more appropriate_ workflow here would be for Twilio to
| cross-check this "spam" with inbound spam into twilio itself
| for some other number his account controls.
|
| Which is to say, if a Twilio account originates a suspect
| message, first check to see that suspect message was sent,
| inbound, to it before auto-DoSing an entire business. This
| shouldn't be too tough, especially since these events probably
| occur in step with each other.
| tobyjsullivan wrote:
| There are two layers here. 1) You're absolutely right that the
| account ends up texting out a phishing link which any automated
| system would rightfully detect as phishing (regardless of
| whether the recipient has "consented" to receiving the message
| - it still contains a phishing link). But that's not the real
| issue, which is 2) Twilio's response to detecting the sending
| of a phishing link (possibly more than one) is to disable an
| entire account with no timely recourse from the affected
| account holder who may be running a legitimate business.
|
| I don't think anyone is arguing that Twilio was wrong to detect
| the message as spam. It's more that an unexpected side-effect
| of the customer's current implementation had outsized
| consequences. Similar unexpected friction with Twilio's anti-
| spam mechanisms are likely to occur again and they will cause
| outsized damage to this legitimate business or others if Twilio
| doesn't change their strategy.
| willcipriano wrote:
| As a text message recipient, I can't say I'm mad about
| Twillo's choice here.
| exsmelliarmus wrote:
| I'm assuming you would be if your business was harmed
| through an honest mistake.
| willcipriano wrote:
| I'm the kind of person who would be mad at my choices in
| that case. If I failed to plan for that sort of thing
| it's on me. "What of someone sends abuse to my text
| message forwarder?" isn't all that out there of a
| question.
| ghusbands wrote:
| While literally the case from what is described, it's clear
| that a consensual (by employment) message forwarding service
| happening to forward received scams/spams is quite different to
| actually scamming/spamming.
|
| I guess it's unlikely that one can make this consent clear to
| Twilio, though, and if the messages aren't distinguishable then
| they might still get seen and reported as spam by the employee,
| with all the bad reputation that can cause for all involved.
| jaywalk wrote:
| Not excusing their lack of support, but at the end of the day
| _you_ sent a spam /phishing message through their service. What
| exactly are they supposed to do? If they don't immediately shut
| down accounts that send these messages, they're going to be in
| hot water with the cellular carriers. It's by far the lesser of
| two evils to just shut down accounts that send spam.
| Turing_Machine wrote:
| No, someone else sent a spam message into Twilio's system, and,
| rather than dropping it on the floor, Twilio's system then
| forwarded the spam on to their customer's list, then blamed the
| customer for it.
| jaywalk wrote:
| Nope, that's not how Twilio works. Yes, someone else sent a
| spam message, but Twilio did not forward it to "their
| customer's list" whatever that means. Twilio forwarded it to
| their customer's _application_ , which was the end of the
| line for Twilio. At that point, _their customer 's
| application_ sent out that spam message to whoever was
| configured to receive it. As far as Twilio is concerned, the
| incoming and outgoing messages have no relation.
| Turing_Machine wrote:
| That's a distinction without a difference.
|
| By their own policy, Twilio's upstream should ban them for
| "forwarding spam".
|
| I'm guessing they would not be happy if that policy were
| applied.
| ewoodh2o wrote:
| This is really frustrating, and sorry you're on the receiving end
| of this. I don't work for Twilio, but we spend a lot with them
| (and some other telecoms) so I see a bit further up the chain
| than most.
|
| The retail wireless carriers are really driving a lot of this
| with recent 10DLC A2P changes. In particular, T-Mobile is waving
| around threats of $10k fines per message for messages they deem
| to be in violation of their content rules. (Which obviously
| prohibit fraud and such, but also somewhat-arbitrarily anything
| relating to marijuana.) The way it's written T-Mobile will fine
| Twilio, who is supposed to pass it on, but knows they'll struggle
| to collect that.
|
| Meanwhile, on my personal cell phone AT&T can't even seem to
| figure out that when they get a message from a Nexmo number that
| starts with "ATT Free Msg" that they didn't send, maybe they
| shouldn't deliver it. As a consumer I'm glad someone is trying to
| squash these scams, but they're breaking more than a few eggs in
| the process.
|
| I'd echo the advice to get off the SMS channel for notifications
| if at all possible, unless you're sending enough and spending
| enough to have named support contacts. The rules are being
| written for people sending thousands of messages per day. We
| serve small businesses who send maybe 100 messages per month, and
| it's been a mess trying to get carriers to recognize that these
| businesses exist and need a solution that works for them too.
| starwind wrote:
| Spam texts like that basically destroyed my phone number that
| I've had for 15 years :(
|
| "You package (#US853121) containing the following products: 1.
| iPhone 13. Cannot be delivered until outstanding duties have
| been paid. Current outstanding balance: $1.68. More info
| <sketchiest website ever>"
|
| I get about 20 of these a day. I've lodged multiple complaints.
| Like, why can't AT&T solve this problem that AOL solved in
| 1994?
| lowbloodsugar wrote:
| I suspect you just have to pay for it _and_ allow them to
| read and retain and aggregate your messages and use them for
| advertising.
| jrockway wrote:
| My thought is that for any business-critical service, you need to
| have bought the service from person-to-person sales channels.
| Many boring meetings where they walk you through a slideshow of
| their service even though you already have it working. Many
| meetings worth of negotiating a price that's 10x the off-the-
| shelf price. All instead of, you know, making your product. It's
| just the cost of doing business -- $5/user/month if you're ok
| with them shutting you down because of a malfunctioning cron job,
| $30,000/year + meetings if you want someone's email that has to
| look into your problem. That's how software is these days, and
| unfortunately, literally everyone wants a piece. No task is too
| trivial to justify a 5 figure yearly cost, it seems. (Most
| recently, a well-known company tried to get that much out of me
| for hosting a static website!) There doesn't seem to be any
| market pressure to correct this problem, and I don't really
| understand why, but someone stands to make a lot of money if they
| crack the code. In the meantime, there's you and a problem, and
| giving the vendor your time and money can get the problem
| resolved. (Yup, you have to reward someone that's wronged you,
| because you already wrote code against their proprietary API.
| That's just how it is these days, and you have to accept it if
| you want to get anything done.)
|
| I agree with the other comments that relaying phishing to
| internal users is probably what they dislike. There, of course,
| isn't a good solution beyond using some open platform. Your self-
| hosted IRC server isn't going to cancel your account because
| someone sent a phishing link, for example. But, nobody will know
| how to connect to it anyway. Sigh!
| ChrisDutrow wrote:
| I kind of agree with this. I need to have that point-of-
| contact, so that if something blows up, they don't want to lose
| their commission, so they email the right person in the company
| to get it fixed.
|
| The thing is, I actually had this when I first started with
| them. They were so small at the time, that I had one of the
| founders on the phone once and he told me all about how he
| studied cloud computing at MIT. But this was over 10 years ago.
| After that, they had phone support for a long time.
|
| Last few years they changed over to this way where there is no
| path to resolving a problem like this, which should be easy to
| solve, in an appropriate amount of time.
| jbkiv wrote:
| Makes total sense. If you buy a subscription for few
| dollars/month, don't expect a human being to answer your call.
| Google/Twillio/Sendgrid, whatever the service, all the same
| ticketing system and no real answer.
|
| HN crowd looks down on sales reps. But a good sales rep will 1)
| understand your business 2) will look for ways to match your
| needs to solutions they offer 3) will be your point of contact
| when things go wrong.
|
| Sales reps are human beings, treat them well, thank them for
| their time if you don't buy the fancy/expensive enterprise
| plan.They'll understand. Most reps are young college grads that
| are building a network for life.
|
| You could be a solo SaaS creator and cheap because it is a side
| gig and your don't have the money. But still make an effort to
| nurture those little young reps. One day they'll make the phone
| call to somebody that will remove that account suspension. That
| will save your business.
| helloworld11 wrote:
| I've dealt with several web hosting companies that had fully
| human operators respond very nicely when I had a problem even
| though my monthly hosting fees were tiny, rarely more than
| $20 per month. It's not impossible to offer a low cost
| service and still avoid being an unresponsive piece of shit
| to clients.
| ChrisDutrow wrote:
| Yeah GoDaddy and HostGator are like this.
|
| Amazon EC2 is not.
|
| Also Google treats businesses like this if they have
| profiles on their maps. A business might rely on their
| google maps profile for 100k+ in revenue, but they can't
| get someone from google on the phone to help deal with it.
| I had someone steal my google maps listing from me and they
| got away with it because google would not connect with me
| about it. It was horrible and it was wrong.
| rubatuga wrote:
| Seems like it's his fault. I'm currently using the twilio API. A
| simple Python script could be used to filter out any messages
| that weren't sent from an employee. He essentially has an
| unauthenticated open relay, a one way ticket to get put on a spam
| blacklist in the SMTP world.
| maerF0x0 wrote:
| Except that "open relay" is to very specific numbers, not to
| just any # . I would like to think there must be a way to send
| whatever to authenticated / opted in numbers?
|
| DISCLAIMER: I do work for TWLO, but on a completely unrelated
| division. My opinion and this message does not represent my
| employer in anyway. I'm just shooting the breeze here.
| yosito wrote:
| Suggestion to Twilio, if you're reading: if you have the ability
| to detect spam messages, perhaps give your users an API call for
| filterSpamAndSend instead of just send.
| alberth wrote:
| The carrier (ATT, Verizon, etc) probably flagged this as spam -
| not Twilio.
| grouseway wrote:
| For an alternative, maybe relay the texts to a slack channel
| (that's easy enough to receive on a phone for your coworkers).
| Zapier can probably integrate twilio/slack quickly.
| howdydoo wrote:
| Then what do you do when Slack bans your account?
| mfkp wrote:
| Self-host Zulip - which in my opinion is better than Slack
| anyway and supports slack incoming webhooks.
|
| https://zulip.com/
| ChrisDutrow wrote:
| Yes, I will do something like this. However it doesn't
| alleviate the overarching concern that they are behaving in a
| way that treats my business very recklessly.
| somehnguy wrote:
| I use Slack like this for various notifications. I just setup a
| new Slack instance and created channels for each notification
| area (smart home, media server, etc). Now all the software in
| those various areas can send messages (via webhook) and I can
| set the alert preferences per channel. Makes it easy to quickly
| look at Slack and know things are running fine.
|
| I also have a #critical channel anything can post to that
| always has alerts enabled on my phone so I don't miss anything
| important.
|
| It actually works pretty well and costs nothing.
| marcosdumay wrote:
| > I should be considering bearing in mind that it would be
| expensive to re-write the software to work with another vendor
|
| Well, maybe next time you get somebody that implements a
| standard.
|
| With that kind of behavior (not letting you speak to anybody, the
| blocking is understandable), it's clear you shouldn't keep their
| services. So, you have now an opportunity to do it right, and
| make the next move cheaper.
| yellow_lead wrote:
| There isn't a standard for these apis though
| toast0 wrote:
| SMPP is a standard for sending and receiving text messages.
| The standard body is dissolved and you have to grab the
| documents from random places, but that doesn't make it less
| of a standard. There's also a SOAP standard for SMS that GSMA
| put out, but it's SOAP bleh. I think there's supposed to be a
| newer GSMA standard that's not SOAP garbage, but I retired.
|
| There isn't really a standard for the interactive voice
| processing, SIP is a standard, but it's not quite simple to
| use it compared to Twilio or similar APIs.
|
| However, most of the providers in this space have fairly
| simple APIs, so it's like 30 minutes of work to do the
| integration, maybe a little more if you're also receiving SMS
| or if URLs are particularly hard to use in your language of
| choice; if you're adding yet another SMPP vendor, that's
| faster, if you're adding yet another GSMA SOAP vendor, it's
| probably longer because you'll have to figure out why your
| XML doesn't work even though it should. Plus whatever it
| takes to get the account setup. Plus however long to build a
| way to choose from multiple providers (this part may be a lot
| of work!), and however long you want to run with limited
| traffic to see if the new provider does better/worse/same as
| the old provider.
| marcosdumay wrote:
| VoIP is entirely based on SIP, everywhere. Those providers
| just add a proprietary API over it. But if the use case is
| just sending texts, that one may evade the standard (I don't
| remember it entirely, and it certainly evolved since last I
| used it).
|
| But then, if they were only sending texts, migrating wouldn't
| be expensive.
| nawgz wrote:
| It's quite strange you forward the texts VIA text; why not ingest
| it in any other format? Slack, internal database, logs, ...
|
| Unfortunate outcome though. Automated banning is always
| frustrating.
| ChrisDutrow wrote:
| I need the message to pop up on his cell phone just in case he
| is not at the computer.
|
| Slack is probably a good idea.
|
| Of course we have an internal database and he can look at text
| messages through our web application too. But these are not
| push notifications to his phone.
| stefantalpalaru wrote:
| jeffiel wrote:
| Hi Chris - CEO of Twilio here. I'm sorry for the issue. Fighting
| bad actors sucks, but we can do better to communicate with good
| faith builders like yourself. Mind sending me a note with your
| account at jeff@twilio.com, and I'll escalate for you.
| quadrifoliate wrote:
| A request from a random HNer - could you also commit to
| observing what the user's interactions with your customer
| service have been so far; and improving each of those, instead
| of nebulously "escalating" (where people will unblock an
| account because the CEO mandated it from up on high)?
|
| Otherwise, you are contributing to a pattern where HN becomes
| de facto Tier 1 Customer Service, similar to how Twitter was a
| few years ago. This is already the case for various Google
| services [1], but I would hope that we don't want to normalize
| it for _every_ service.
|
| ----------------------------------------
|
| [1] A familiar pattern to most of us - Ask HN: Google suspended
| my account without warning; Googler escalates internally;
| problem is solved
| djyaz1200 wrote:
| We were paying them around $1500/mo and had a similar issue where
| they blocked some (in our case) legitimate messaging traffic. We
| switched most of our traffic to another provider and are pleased.
| We had been a Twilio customer since 3 days after they launched
| and I owned a significant amount of their stock. I sold it all
| when this happened in spring of last year and I'm glad I did...
| stock has gone down significantly since. I don't see Twilio doing
| well long term, they provide an API for a network they don't own.
| techsupporter wrote:
| Where I work, we use Pushover (https://pushover.net/) for this. A
| message comes in via SMS and then a handler stores it in a
| database then turns around, does some light filtering[0], and
| then sends a notification to a Pushover group. It's $5 per user
| per month for their teams feature, which we happily use.
|
| 0 - The handler doesn't send out via Pushover any message that
| contains words we're unlikely to use; Facebook is one, for
| example. If a message isn't forwarded via push notification, it
| is emailed to the sysadmin list for one of us to manually look at
| during daytime hours.
| ChrisDutrow wrote:
| Oh very cool, thanks for this suggestion. I think the outgoing
| text messages actually add up to be kind of expensive too so
| this could save some money.
| _hyn3 wrote:
| Wonder if it runs on Twilio..
| techsupporter wrote:
| I don't know what the SMS service part of Pushover uses as we
| don't send SMS through Pushover. The part we use, the main
| feature, sends a notification through an app the user
| installs on their device. All of us who receive push
| notifications through our system have the Pushover app on our
| phones, some also have it on their tablets and computers.
|
| I like the Apple Watch integration as I can interact with
| urgent notifications just on my watch without my phone handy.
| toss1 wrote:
| No experience with Twilio, but yours makes me glad that's not the
| case.
|
| As another small biz, I've had very good experience with
| Phone.com over the past several years. Prompt and solid tech
| support the few times I need it (mostly for configuration and 'is
| there a way to do this peculiar thing?' questions), and mostly
| just works.
___________________________________________________________________
(page generated 2022-01-06 23:01 UTC)