Tag Archives: Uncategorized

Introducing the enhanced command line interface in Amazon Q Developer

Post Syndicated from Brian Beach original https://aws.amazon.com/blogs/devops/introducing-the-enhanced-command-line-interface-in-amazon-q-developer/

Earlier today, Amazon Q Developer announced an enhanced CLI agent within the Amazon Q command line interface (CLI). With this announcement, Q Developer brings the latest agentic experience to the CLI that provide a more dynamic, interactive coding experience that works with you, and iteratively makes changes based on your feedback. Amazon Q Developer can now use the information in your CLI environment to help you read and write files locally, query AWS resources write code, or automatically debug issues.

Introduction

As a developer, I appreciate my Integrated Development Environment (IDE) along with the integrated linters and auto-completion features that help streamline my workflow. The addition of AI assistants, like Amazon Q Developer, have changed the way I work in profound ways. I can discuss best practices with Q Developer in chat, or ask it to refactor a complex method in seconds. I am increasingly using the Amazon Q Developer agents to develop new features, write documentation, generate unit tests, and automate code reviews. These powerful agent capabilities have further transformed how I approach my daily development tasks.

However, as a developer, I spend as much time at the command-line interface (CLI) as I do in the IDE, maybe even more. Tools like the Amazon Web Services (AWS) CLI, Git, package managers, and linters have revolutionized the way I manage infrastructure, automate repetitive tasks, and collaborate with my team. Tools like Docker and Kubernetes have transformed the way I develop and deploy my applications. Looking at the extensions tab in my IDE, I have extensions installed for Maven, Docker, and Vue, but I rarely use them, preferring the flexibility and power of the CLI.

Amazon Q Developer has been available in the CLI for over a year now, and it has become an indispensable part of my daily development routine. The assistant’s ability to provide intelligent command completions that can list my Git branches, Amazon S3 buckets, etc. has saved me countless hours. The chat feature allows me to engage in natural language conversations with Amazon Q Developer, asking it to help me learn how to accomplish specific tasks, while the translate capability seamlessly converts my plain-language prompts into the corresponding shell commands.

While Amazon Q Developer’s CLI capabilities are helpful, I miss the power of the agents I have access to in my IDE. Earlier today, Amazon Q Developer announced an enhanced CLI agent within the Amazon Q CLI. Amazon Q Developer, and the new agent is powered by Amazon Bedrock, as a result, the CLI has the power of Claude 3.7 Sonnet step-by-step reasoning. In addition, the new CLI agent can make use of tools installed on my system including compilers, package managers, and the AWS CLI. Finally, the enhanced CLI supports multi-turn conversations allowing dynamic, back-and-forth conversations with the agent. This enables me to get more work done, faster, without ever leaving the comfort of my preferred command-line environment.

Rather than being constrained by the features and workflows of an IDE, the CLI agent gives me direct access to the underlying tools and commands I need to get my work done. Let’s look at an example.

Walkthrough

To see how the CLI agent capabilities work, I’ll walk you through an example. I’m preparing for an internal developer community summit happening in April. I need an application to manage the call for content. The Call for Content application allows community members to propose topics for the summit. I’m going to use the Amazon Q Developer CLI to build the application.

I already have the CLI installed, so I’ll run q chat to begin a new conversation with the agent. Then I will ask Q Developer to “scaffold a new application named call-for-content using React and Vite, and then commit it to Git.” As you can see in the following video, the agent understands my intent, and carries out the work needed to build the application. In the past, the Q Developer CLI would provide instructions for me to execute. In this new enhanced version, the CLI agent uses the tools installed on my laptop to complete each step for me. I should note that I have disabled confirmations, but Q Developer can prompt me before each action so I can verify it.

Animated screen recording of a terminal window showing Amazon Q Developer CLI in action. The terminal displays a welcome message 'Hi, I'm Amazon Q. Ask me anything.' The flow of events in the recording is captured in the next image.

The agent is working quickly in that video. So quickly that is hard to keep up. So I broke it down, step-by-step in the following image. The agent begins by calling npm create to create the new app, followed by npm install to add all the dependencies. It then runs a series of git commands to create a new repository, add my files, and commit the changes including a descriptive commit message.

Terminal screenshot showing a sequence of commands executed by Amazon Q Developer to create a new React application. The sequence includes: creating a new Vite React project called 'call-for-content', installing dependencies with npm install, initializing a Git repository, adding files to Git, and making an initial commit. Each command is preceded by 'Execute shell command' and shows the exact command to be run in green text.

Notice that agent is not simply generating files. It is running the same commands that I would have run on my own. However, the CLI agent is doing it much faster, and more accurately than I could have done. The enhanced Amazon Q Developer CLI can use tools, including other command line tools installed on my system, to complete its work. Once Q Developer is done, it provides me a summary of the work it has completed, and suggests next steps. In the following image, you can see that Q Developer is suggesting I run the development server to preview the changes. That is a great suggestion, so I ask Q Developer to start the server and confirm that everything is working.

Split screen view showing two panels. On the left, a terminal displays a summary of completed actions including project creation, dependency installation, and Git initialization, along with instructions for starting the development server. On the right, the default Vite+React application page showing the Vite and React logos, a counter set to 0, and instructions to edit src/App.jsx to test Hot Module Replacement.

With the application template running, I’m ready to start building the Call for Content application. The CLI agent supports multi-turn conversations, so I can pick up where we left off. I simply explain my requirements at the command line, and agent begins to generate code. This is what Amazon Q Developer does best. In this example, it needs to update the App.jsx and App.css files.

Terminal screenshot showing Amazon Q Developer processing a request to create a form application. The sequence shows: a prompt requesting a form with specific fields, followed by status messages indicating updates to App.jsx (completed in 0.1s) and App.css (completed in 0.2s), and ending with a Vite server startup message showing the local development server running at http://localhost:5173.

Notice that the agent can read and write files on my local system in addition to running commands as we saw in the prior example. So, as Q Developer generates code, the agent can put it in the correct place in my local file system. Once it is done, the agent starts the development server using npm run dev. I asked it to start the server last time, so it correctly guesses that I will want to check the progress. Just like last time, the agent provides another summary of the changes it made. Personally, I appreciate these periodic summaries. They help me build confidence in the work that Q Developer is doing. I’m not happy with the color of the title. I could ask Q Developer to update it, but I will simply update the file myself. Note that I can edit files on my own while using the CLI. the agent will read files before editing them to check if I have made any changes manually.

Split screen view showing development results. Left panel contains terminal output describing the form's features including field validations and counters. Right panel shows the rendered web form with fields for Name, Email, Talk Title (with 0/100 character counter), Abstract (with 0/100 word counter), Talk Level dropdown defaulted to '100 - Introductory', and a blue 'Submit Talk Proposal' button at the bottom.

The application is looking great! However, it is currently writing it’s output to the console. I never told the agent what to do with the data. I would like the application to write to a DynamoDB table. In fact, I created one already. However, I cannot remember which region the table is in. In the following image, I ask the agent to figure it out for me. Let’s see how it responds.

Terminal window showing a sequence of AWS DynamoDB commands. The initial prompt asks to update an app to write to a DynamoDB table named 'call-for-content'. The sequence shows three 'Execute shell command' operations: first checking the table in us-east-1 region, then in us-west-2 region, followed by installing AWS SDK dependencies. The final line shows successful creation of a new DynamoDB service file.

As you can see in the prior image, the agent is able to think about my vague request, and figure out what to do. It starts by looking in us-east-1. When it can not find the table, it moves to us-west-2 and tries again. The table was in us-west-2, but if it were not, the agent would have continued searching. Q Developer understands how to list and describe AWS resources. Once the agent found the table, it uses npm to install the DynamoDB SDK, and then updates the application files. Note that the agent actually updated multiple files, but I kept the image simple.

With just a few simple prompts, I was able to use the enhanced CLI agent to collaborate with Q Developer throughout the entire development process. I’ll keep working on the application to add authentication, etc. However, I assume you have a good understanding of how the Q Developer CLI works and are eager to get started. So, let’s stop here.

Conclusion

Amazon Q Developer’s new CLI agent has completely transformed the way I approach software development. By bringing the power of an advanced AI assistant directly into my preferred command-line environment, I can now accomplish complex tasks faster than ever before. Q Developer’s natural language understanding and contextual awareness, combined with the CLI agent’s ability to reason and use a wide range of development tools, make it an indispensable part of my daily workflow. Finally, support for multi-turn conversations, enable me to collaborate with, and work along side the agent to get more work done, faster.

If you’re a developer who spends a significant amount of time in the CLI, I highly recommend trying out the Amazon Q Developer’s CLI agent. You can follow the Amazon Q Developer User Guide to install the CLI and start leveraging the new agent capabilities right away, for free. I’m confident it will change the way you work, just as it has for me. Give it a try and let me know what you think!

A Guide to SMS Short Codes with AWS End User Messaging

Post Syndicated from Tyler Holmes original https://aws.amazon.com/blogs/messaging-and-targeting/guide-to-sms-short-codes-with-aws-end-user-messaging/

In today’s digital age, SMS messaging remains a crucial communication channel for businesses. One of the most effective ways to leverage SMS is through the use of short codes – those brief, memorable numbers that make it easy for customers to interact with your brand. This comprehensive guide will walk you through everything you need to know about obtaining and using SMS short codes.

What Are Short Codes and Why Use Them?

While short codes aren’t required for sending SMS in most countries(not all) they are synonymous with high throughput and reliability.

They offer several advantages:

  • High throughput – They start out at 100 messages per second
  • Ability to scale to thousands of messages per second – If you need the kind of scale to send out mass alerts in a short amount of time, the best option is likely a short code
  • Higher deliverability rates – Because of the increased upfront scrutiny in the registration process they have less issues with filtering and blocking. Critical use cases such as One-Time Password(OTP)/Two-Factor Authentication(2FA) are use cases that, even if you don’t need the high throughput, you may want to consider using a short code to deliver them
    • Short codes investigate issues before blocking through proactive audits, while other registered originator types such as toll-free or 10DLC block/filter first and investigate later when issues arise
  • Easy for customers to remember and identify – Short codes are 5-6 digit numbers, which is easier for recipients to remember than 10+ and lends credibility and trust to your message

Short Codes Shortcomings

While short codes offer many advantages for SMS messaging, they also come with some things to be aware of

  • Short codes are limited to SMS/MMS functionality only, unlike other number types such as long codes, 10DLC, or toll-free numbers that can also support voice messages. This limitation may restrict your communication options with customers.
  • Carriers consider short codes a premium product, which can lead to higher costs for businesses.
  • The process of obtaining a short code can be more time-consuming and complex than other originators, requiring strict adherence to carrier requirements and a thorough application process that can take several weeks to months to complete. This is not specific to AWS, these processes are controlled by the carriers and countries in which you are applying. For example, some countries require specific supporting documents such as a Letter of Authorization (LOA) or even a copy of a passport of an executive at the company. Be ready to provide these as there are usually no exceptions to these requirements.
  • While it’s an edge case, there are some prepaid mobile plans, like those offered by T-Mobile in the US, that don’t allow their users to receive messages from short codes, potentially limiting your reach.

Do You Need a Short Code?

If you answer yes to any of the below, you might want to consider a short code

  • You need over 20 MPS
  • You need daily volumes over 400K
  • You need higher success rates
  • You want an easily recognizable number for your brand
  • The country you need to send to ONLY allows short codes
  • Ensuring maximum reliability is critical
  • You operate in a highly regulated industry (like finance)

However, keep in mind that short codes:

  • Do not support voice like long codes can
  • Require a more rigorous application process and take longer to obtain
  • Have an increased cost compared to other originator types (Long codes, Toll-Free, 10DLC, Sender ID, etc.)
  • While a small edge case, they may not be supported by some prepaid mobile plans

If you’ve decided that your use case requires a short code, you have to do some planning before you request one. The next few sections guide you through some of the requirements that must be in place in order to obtain and use a short code.

Planning Your Short Code Application

Before applying for a short code, you need to have several elements in place:

1. Understand Consent Requirements

Carriers impose their own, more strict, requirements beyond the minimum requirements of law in many countries. A non-exhaustive list of consent requirements include:

  • Explicit consent is required before sending any messages
    • It does not matter if you are messaging to your employees, sending to 6 people on an IT team, or sending millions of messages promoting your brand, there are no exceptions to this rule
  • Consent must be specific to each message type (no blanket consent)
    • You must obtain explicit consent for each distinct use case such as OTP/2FA, Marketing, and the various flavors of transactional messaging. You can find examples of the distinct use cases that US 10DLC numbers adhere to here which is a good place to start when trying to classify your use cases
  • Consent can’t be transferred between companies
    • The concept of consent lies with who owns the relationship to the recipient. Just because you have received consent for a brand within your portfolio does not mean that you can message someone for a different brand or use case.
    • If you are a SaaS or multi-tenant type customer where you are offering SMS capabilities to your customers, then proof of consent must be supplied by your customer and their information submitted for review.
    • Never sell/rent your list of opted-in customers, and never use purchased or rented lists.
  • Receiving SMS can’t be a requirement for using your service or opting out
    • If your use case requires that you verify your customer’s phone number, provide them an alternative to receiving text messages. For example, provide the option to receive a voice call or an email and opt-out via different channels as well

2. Design Compliant Opt-in Workflows

An in-depth explanation of how to design a compliant opt-in process can be found here. Your opt-in process does not have to be online. You can use verbal scripts, paper forms, or online signups but the location at which someone is opting in must include:

  • A description of message types you’ll send
  • The phrase “Message and data rates may apply”
  • Message frequency information
    • This is a statement such as:
      • “You will receive (1-10) messages per (day/week/month/other)” or “message frequency varies”
  • Links to Terms & Conditions and Privacy Policy or a printed copy if not publicly accessible
  • Opt-out information (example: “Text STOP to opt-out of future messages.”)
  • Communication options
    • If your use case is 2FA/OTP you must supply a secondary channel for receiving the codes, such as email. SMS must be optional and another option must be provided. This is mandated by Verizon in the US.
    • In all other use cases SMS must be optional. It cannot be a requirement for a subscriber to opt in to SMS in order to sign up for a service. As an example: you sign up for a rewards program at a coffee shop and it is mandatory to sign up for SMS in order to join the program. This is prohibited
  • An explicit opt-in
    • Checking a box, signing your name and date, capturing it verbally and logging it. These are all valid forms of explicit opt-in. If you pre-check boxes on your forms that is NOT considered an explicit opt-in and your registration will be denied, increasing the time it will take to get approved.

The image below is an example of an online form. This is a more complex flow but you could also have a single screen flow, as long as it contains all of the above required components. Keep in mind that you can also use verbal scripts and paper forms that include all of the required components above.

Image 1 – Complex

3. Create/Update SMS-specific Privacy Policy and Terms & Conditions

Data privacy is an important component of any SMS program and when applying for a short code the US mobile carriers set the most stringent requirements regarding specific language in your Privacy Policy and Terms & Conditions. If you comply with the below for your Privacy Policy and Terms & Conditions this should put you in compliance for other countries that you may want to apply for.

For a more in depth discussion of the topic of opt-in and compliance please visit

NOTE: You are allowed to create an SMS only section within these two documents to call out different data sharing or other terms that apply to SMS but not to other parts of your business, but these items are non-negotiable and must be present or your registration will be denied by the carriers in the US

Terms & Conditions

Below is the boilerplate language that covers minimum requirements from the US carriers who are the most stringent:

  1. {Program name}
  2. {Insert program description here; this is simply a brief description of the kinds of messages users can expect to receive when they opt-in.}
  3. You can cancel the SMS service at any time. Just text “STOP” to the short code. After you send the SMS message “STOP” to us, we will send you an SMS message to confirm that you have been unsubscribed. After this, you will no longer receive SMS messages from us. If you want to join again, just sign up as you did the first time and we will start sending SMS messages to you again.
  4. If you are experiencing issues with the messaging program you can reply with the keyword HELP for more assistance, or you can get help directly at {support email address or toll-free number}.
  5. Carriers are not liable for delayed or undelivered messages
  6. As always, message and data rates may apply for any messages sent to you from us and to us from you. You will receive {message frequency}. If you have any questions about your text plan or data plan, it is best to contact your wireless provider.
  7. If you have any questions regarding privacy, please read our privacy policy: {link to privacy policy}

Privacy Policy

One of the key items carriers look for in a Privacy Policy is the sharing of end-user information with third-parties. If your privacy policy mentions data sharing or selling to non-affiliated third parties, there is a concern that customer data will be shared with third parties for marketing purposes.

Express consent is required for SMS; therefore, sharing data is prohibited. Privacy policies must specify that this data sharing excludes SMS opt-in data and consent. Privacy policies can be updated (or draft versions provided) where the practice of sharing personal data to third parties is expressly omitted from the number registration.

Example: “The above excludes text messaging originator opt-in data and consent; this information will not be shared with any third parties.”

It can also be an option to put the privacy statement in the Call-to-action mockup if you do not want to have to put it in your privacy policy page.

4. Prepare Message Templates

When submitting your registration, you must provide examples of the messages you will be sending. This includes automated responses triggered by specific keywords from end-users such as “Help“ as well as the outbound messages you will be sending to your recipients based on your use case. While we’ll provide English examples below, note that keywords and responses should be localized based on your recipient countries. You may (and should) configure multiple keywords depending on your audience demographics. All messages must be under 160 characters and meet the specific requirements detailed below:

  • Standard Outbound Messages
    • These will be specific to your program and what your use case is. You do not need to provide all of your messages that you plan on sending but you should provide an example of each type of message that you plan on sending. If you are sending in multiple languages you should provide a version for each language.
  • Opt-in Confirmation Message
    • This is the message that must be sent whenever you opt someone into your program
  • Help
    • This message must be sent when any of the required keywords for help in the country you are registering for are sent back to you. In the US this is “help” and in Mexico this is “ayuda” for example.
  • Stop
    • The “Stop message” is the response that is required to be sent to end-users when they text the keyword “STOP” (or similar keywords). End-users are required to be opted out of further messages when they text the STOP (or equivalent) keyword to your number and you are required to confirm with them that they will no longer receive messages for the program.

Let’s review the specific requirements for each in detail

Standard Outbound Message Types:

Your short code application must include examples of all of the message TYPES that you plan to use but it does not need to include ALL of the possible examples. This is especially true with promotional messages that can have a lot more variability. You need to give the reviewers enough examples that you are illustrating how you will be using the short code.

The two main types of messages are Promotional and Transactional, let’s break each down.

Promotional: This includes any type of messaging that has content related to sales or other offers. This does not only have to be related to content that requires a purchase. This could also be marketing new features, announcing the launch of a new program, or other messaging that could be construed as marketing. Remember, there are humans reviewing these registrations so make sure that any messages that you are using will not be misconstrued as a type of message that you are not registering for.

Transactional: There are a lot of different types of messages that can be considered transactional. The simple way of thinking about it is that anything that is NOT promotional, is transactional. Some examples of transactional messages include:

  • Account Notifications
  • Status notifications about an account that the recipient is a part of or owns
  • Customer Care
  • Communications related to support or account management
  • Delivery Notifications
  • Notifications about the status of a delivery of a product or service
  • Fraud Alert Messaging
  • Notifications related to potential fraudulent activity
  • Security Alerts
  • Notifications related to a compromised software or hardware system that requires recipients to take an action
  • Two Factor Authentication(2FA) or One-Time Password(OTP)
  • Authentication, account verifications, or one-time passcode

While these two types can be mixed on a single short code we strongly recommend against this:

  • Mixing message types on a single code is not as resilient should something happen to your code or if your code is ever audited.
  • It could prevent your recipients from accessing their account if they opt out of a code delivering OTP and marketing messages and you are not self managing your opt out process.
  • It can also impacts the throughput — if, during a marketing campaign using the same short code, that campaign is exhausting the throughput of the short code, the transactional use case will be impacted by that capacity limitation.

Best practices:

  • Include your Program (brand) name in each message
  • If you have multiple templates, include an example of all of the types you are registering for.
  • Read them all and make sure that they are clearly a part of the message type/use case that you are registering for
  • If your messages will include variables, it’s fine to use either placeholder values or variables.
    • For example, both of the following are acceptable: “Hello John. Your one-time password is 654321” and “Hello [first_name]. Your one-time password is [otp code] .”
  • Make sure they are all less than 160 characters
  • Do not use unbranded link shorteners
    • If you have to use a shortener make sure that it is branded and that there are not multiple redirects. Also make sure to provide examples of the branded shortened domain so that it is on file with the carriers

Confirmation:

Provide the exact message that will be sent back to your end-users letting them know that they have successfully registered.

Example:
“Welcome to AnyCo! Reply “YES” to confirm your subscription and get special offers once a month. Msg & data rates may apply. Text ‘STOP’ to opt out.”

You must include:

  • The message has to be a minimum of 20 characters and a maximum of 160 characters
  • Brand Name
  • Opt-in confirmation messages are required for all use cases, even one-time passwords. However, for OTP-type use cases, the act of end users requesting an OTP is essentially an opt-in and associated confirmation message which means you don’t need another unique confirmation message on top of the OTP as long as the OTP message is compliant.
    • A double opt-in confirmation message flow, where the recipient will text back “YES” to confirm that they did want to register, is only required for shopping cart reminder use cases. However we do recommend it as a best practice for all use cases since it ensures you are maintaining a clean database of numbers.
  • Include “Msg & data rates may apply” as seen in the example
  • Include opt-out language as seen in the example

Help:

Provide the exact message that will be sent back to your end-users when they request “help” via keyword response.

Example:
“ExampleCorp Account Alerts: For help call 1-888-555-0142 or go to example.com. Msg&data rates may apply. Text STOP to cancel.”

You must include:

  • The message has to be a minimum of 20 characters and a maximum of 160 characters
  • The message must include:
    • Program (brand) name OR product description.
    • Additional customer care contact information.
      • It is mandatory to include a phone number and/or email for end-user support
  • Include “Msg & data rates may apply” as seen in the example

Stop:

Provide the exact message that will be sent back to your end-users when they request to be opted out of your program. You are allowed to include instructions on how to resubscribe but be sure to keep the total message length under 160 characters while still including all of the required components.

Example:
“You are unsubscribed from ExampleCorp Account Alerts. Text JOIN to resubscribe. No more messages will be sent. Reply HELP for help or call 1-888-555-0142.“

You must include:

  • The message has to be a minimum of 20 characters and a maximum of 160 characters
  • The message must include:
    • Program (brand) name OR product description
    • Confirmation that no further messages will be delivered

How to Apply for a Short Code

Step 1: Create a Case in AWS Support Center

Currently short codes are only available by opening a case. The first step to register a short code is to open a short code request case in the AWS Support Center, providing detailed information about your use case and opt-in policies. A request must be opened for each country in which you want a short code. Each country has their own registration process and requirements so having a case for each allows for much easier tracking and updating as there are communications going back and forth between you, the customer, support, and any downstream clarifications that may come back.

Step 2: Complete the Short Code Application

Each country may have different requirements for the information you need to fill out as well as supporting documents you may need to provide. Make sure that everything you submit is 100% correct to your knowledge, as any missing information or information that needs to be corrected extends the time it takes to receive your short code. The minimum information you will need to provide is:

  • Company information such as legal name and tax ID
  • Use case details
  • Opt-in workflow documentation
  • Privacy Policy and Terms of Service
  • Message templates (including CONFIRMATION, HELP, and STOP responses)

The short code application form contains all of the information that we send to the carriers to let them know about your use case. For this reason, the form must be filled in completely, and the responses must all be compliant with the requirements of the carriers. The high-level process looks like the below:

  1. Submit your request for a short code through the AWS case console
  2. AWS will respond back with the appropriate form and required supporting documentation for the country you are applying for.
  3. Fill out the document with all of the information and include any supporting documents required. Don’t leave anything blank, there are no exceptions to these forms.
  4. AWS will validate that the form is complete and supporting documentation is included. We do not review your documents, so make sure that to your knowledge they are correct.
  5. AWS will submit your form to be carefully reviewed.
  6. The registrar reviews documentation to ensure that it is compliant with all carrier and country requirements.
    1. This step may have several rounds of revisions. If you requested through an AWS support case, make sure you are CC’d to updates so you can quickly address any feedback from external reviewers as delays in responses increase the timeline.
  7. Once your documentation is considered compliant your company will be submitted for vetting. This is similar to a credit check process where your data will be validated and you will need to prove you are a member of your company through a domain validation email.
  8. Once the vetting process is completed your short code moves to “carrier review” state — this is when the timer starts. Continue to monitor your case for any needed updates.
  9. The short code numbers are confirmed and the number is provisioned to your account and billing starts. This does not mean that the number can be used however as there are configurations with carriers that need to be completed.
  10. Carriers approve and provision the SC to their network to make it active
    1. This is the final external provider phase. This process requires each individual carrier to review your registration, approve it, and then to provision the code to their networks so that it is active when handed over to you. In rare cases, an individual carrier may reject your registration and request changes or additional information before they approve.
  11. Our SC partner informs us the SC is now approved and active on carrier networks
  12. AWS updates your case informing you that the SC is ready to use

Conclusion

Obtaining and using SMS short codes requires careful planning and adherence to the strict requirements set forth by the carriers. By following the guidance provided in this comprehensive guide, businesses can navigate the application process successfully and leverage the unique advantages of short codes for their SMS messaging needs.

Key to the successful procurement and usage of a short code is the establishment of compliant opt-in workflows, SMS-specific privacy policies and terms of service, as well as the preparation of required message templates. By meticulously addressing these prerequisites, businesses can streamline the application process and avoid costly delays or rejections.

The high bar for obtaining a short code exists to protect consumers from spam and abuse, ensuring that only approved and legitimate use cases are granted access to this powerful communication channel. While the application process may be time-consuming and complex, the benefits of using a short code – including high throughput, reliability, and an easily recognizable brand identifier – make it a valuable investment for businesses that need to communicate with their customers via SMS at scale.

Ultimately, the diligence required to obtain and properly utilize a short code pays dividends in the form of a highly effective and trustworthy SMS messaging channel. Following the guidance outlined in this document will position businesses for success in leveraging the power of short codes to connect with their customers in today’s digital landscape.

A Guide to Optimizing SMS Delivery and Best Practices

Post Syndicated from Tyler Holmes original https://aws.amazon.com/blogs/messaging-and-targeting/a-guide-to-optimizing-sms-delivery-and-best-practices/

If you’re sending critical SMS messages to your users including one-time passwords (OTP), appointment reminders, urgent alerts, and marketing messages, you know how important reliable delivery is. SMS has become the backbone of modern business communications, and for good reason. Its ubiquitous nature and high engagement rates make it the go-to channel for reaching users globally.

But here’s the thing. As your messaging volumes grow and you rely more heavily on SMS for critical communications, you might notice that not every message gets delivered exactly as planned. And that’s normal across the entire telecommunications industry. In fact, expecting 100% delivery rates for SMS messages is like expecting every flight to arrive exactly on time. It’s simply not realistic given the inherent complexity of global telecommunications networks and systems. This isn’t unique to any particular messaging provider. It’s the nature of SMS delivery itself. Don’t worry, you’re not alone. Let’s dive into why this happens and show you how to build a rock-solid messaging strategy that works for your business.

In this post, we’ll explore what really happens when you send an SMS, share practical monitoring techniques that go beyond basic delivery receipts, and show you how to build redundancy into your messaging architecture. By the end, you’ll have the knowledge and tools to optimize your messaging operations using AWS End User Messaging.

Understanding SMS Delivery Complexities

Have you ever wondered what happens when you hit send on that crucial OTP message or important customer alert? The journey your message takes is more complex than you might think. Let’s break it down.

Your message begins its journey through a network ecosystem that involves multiple carriers, systems, and devices before reaching your end user. While this might sound daunting, AWS End User Messaging works continuously to optimize and simplify these delivery paths and maintain strong relationships within the messaging ecosystem.
So what makes SMS delivery so complex? Think of it like air travel – even with the best airlines and optimal conditions, various factors can affect whether a flight arrives exactly on time. The same is true for SMS messages.

Network infrastructure plays a crucial role. Just as flights navigate through different airspaces, your messages traverse carrier networks to reach their destination. AWS End User Messaging actively participates with SMS providers, carriers, and regulators to ensure up-to-date compliance and optimal delivery performance. However, just like air traffic control might need to redirect flights, message routing isn’t always straightforward. Network congestion, carrier maintenance (both scheduled and unplanned), country regulatory changes, and handset network availability, can occasionally affect message routing.

Carriers add another layer of complexity. Each carrier has its own set of rules and policies – think of them as different airports with their own specific regulations. They implement various filtering and anti-spam policies, handle message queuing differently, and may occasionally block messages without proactive notice if they detect suspicious patterns or unusual volumes. This is actually a good thing – it helps protect users from fraud, even though it can sometimes affect legitimate messages.

Then there’s the final destination – the end user’s device. Even if your message successfully navigates the network and carrier challenges, the recipient’s phone might be turned off, in an area with poor coverage, or simply out of storage space. It’s similar to a passenger missing their flight because their vehicle broke down on the way to the airport. Like the passenger, SMS connections may be lost due to local transportation issues at their destination.

This is why focusing solely on delivery reports doesn’t tell the whole story. For instance, you might receive a successful delivery receipt from a carrier, but the end user’s phone could be in airplane mode. Or conversely, a message might show as undelivered in carrier reports, but the user actually received it after a slight delay.

Understanding these complexities helps explain why achieving 100% delivery rates isn’t realistic. Instead of pursuing perfect delivery rates, successful messaging strategies focus on multiple factors:

  • Building comprehensive monitoring systems,
  • Following messaging content best practices (such as using Global System for Mobile Communications (GSM) characters,
  • Maintaining appropriate message lengths,
  • Following URL best practices
  • Ensuring compliance with carrier requirements
  • Providing alternative delivery channels.

Next we will dive deeper into some of these and explore how to set up effective monitoring practices that give you real insight into your message delivery success.

The Reality of Delivery Rates

Let’s address something important: if you’re expecting 100% delivery rates for your SMS messages, you’ll need to adjust those expectations, as this is not the reality of the industry. This is true regardless of which messaging provider you use – it’s simply the nature of how SMS works within global telecommunications networks. Even in optimal conditions, various factors can affect delivery:

  • Network conditions in different countries
  • Carrier policies and filtering systems
  • End-user device states
  • Local regulations and requirements
  • Natural or infrastructure disruptions (for example: cable cuts, wildfires, tsunamis, or other environmental events)

Think of it like this: even the world’s most reliable airline can’t guarantee every flight will arrive exactly on time. Weather patterns change. Airports face congestion. Maintenance needs arise unexpectedly. SMS delivery navigates similar real-world challenges.

What matters is understanding what “good” looks like for your specific use case. Just as an 85% on-time arrival rate might be excellent for flights in winter conditions but below average in clear weather, a 95% SMS delivery rate might be excellent in one country but below average in another. This is why establishing baseline metrics for different regions and message types is so crucial.

Strategies for Reliable Delivery

Now that we understand why 100% delivery isn’t realistic, let’s talk about strategies to maximize your success rates.

The Art of the Retry

When a message doesn’t get through, having a retry strategy is crucial. But it’s not as simple as “try, try again.” You need to be thoughtful about:

  • How long to wait between attempts
  • How many times to retry
  • When to switch to a different channel
  • The cost implications of your retry strategy

Think of it like following up on an important email – you wouldn’t send the same email every 5 minutes, but you might try different approaches over time.

Important Anti-Abuse Note: Always implement reasonable limits on your retry features. This prevents both intentional and unintentional abuse of the system, ensuring fair usage and maintaining the integrity of the service for all users.

This retry strategy forms just one part of a comprehensive approach to reliable message delivery. Later in this post, we’ll explore how to build additional resilience through multi-channel messaging strategies that give you multiple paths to reach your users.

Establishing Effective Monitoring Practices

Let’s talk about what really matters: knowing if your messages are actually reaching your users. Sure, carrier delivery receipts are useful, but they’re just one piece of the puzzle. Just as airlines don’t rely solely on flight trackers to measure success, you need a more comprehensive view of your messaging performance.

So how do you get the full picture? It starts with understanding what “normal” looks like for your messaging patterns.

Getting to Know Your Baseline

Just like you know your typical website traffic patterns or customer service volume, you need to understand your typical message delivery patterns. What’s a normal delivery rate for messages to India versus messages to the United States? How do your success rates vary between weekdays and weekends? What about during peak shopping seasons?

This baseline knowledge becomes your compass – helping you quickly spot when something’s not quite right. But how do you build this understanding? This is where AWS End User Messaging Message Feedback API comes in handy.

Putting the Message Feedback API to Work

Here’s the thing about carrier delivery receipts: they can take up to 72 hours to arrive and will vary by country. That’s like waiting three days to know if your customer got their one-time password! Instead of playing this waiting game, you can use the Message Feedback API to gain real-time insights into message delivery.

Let’s say you’re sending OTP codes. When a user successfully enters their code, that’s a clear signal they received your message. With the Message Feedback API, you can record this action, marking the message as successfully delivered. Not only does this give you immediate feedback, but it also helps build a more accurate picture of your actual delivery success rates.

But what about messages that don’t get a response? After an hour without user interaction, the Message Feedback API will mark these messages as failed. This helps you maintain accurate metrics and quickly identify potential delivery issues.

Building a Complete Monitoring Strategy

Your monitoring strategy should be like a flight operations center, combining multiple data sources and ready to respond to changing conditions.

Message Feedback Data: This is your real-time insight into user interactions. Are recipients completing the actions your messages are meant to trigger? Are OTP codes being used? Are links being clicked?

CloudWatch Metrics: Set up alerts that make sense for your business. If your typical OTP conversion rate is 85%, you might want to know if it suddenly drops below 80%. Remember, these aren’t perfect numbers, and they’re not meant to be. Different messages might need different thresholds. What’s acceptable for a marketing message might not be acceptable for a security verification code. The key is understanding your normal delivery rates and monitoring for significant deviations from that baseline. See here for more information on setting up CloudWatch for End User Messaging.

User Behavior Patterns: Pay attention to how users interact with your messages. Are certain types of messages more successful than others? Do some regions consistently show different patterns? This information is gold for optimizing your messaging strategy.

The key is to look for patterns. Maybe your delivery rates dip at certain times of day, or perhaps specific types of messages have lower success rates. These patterns help you adapt and improve your messaging strategy over time.

Remember, monitoring isn’t just about catching problems. It’s about understanding your messaging ecosystem and continuously improving it. When you do spot an issue, you’ll need to know how to investigate and resolve it quickly.

Investigation and Troubleshooting Strategy

Even with the best monitoring in place, you’ll occasionally run into delivery challenges. Just as airlines have procedures for investigating flight delays, you need a systematic approach to investigate and resolve messaging issues quickly.

Spotting the Signs

Just as air traffic controllers monitor multiple indicators for potential issues, your messaging system has key indicators that signal when something needs attention; your most reliable indicators come directly from your customers’ experiences:

  • A sudden drop in OTP conversion rates
  • An uptick in customer complaints about missing messages
  • Unusual patterns in your message feedback data
  • Spikes in failed delivery attempts

Customer-driven signals are your most accurate indicators of messaging health. When these metrics change significantly, particularly in one-time password (OTP) conversion rates and customer complaints, it’s crucial to investigate the underlying causes and understand their impact on user experience.

Playing Detective

When you notice something’s off, start by narrowing down the scope. AWS End User Messaging provides detailed event data that helps you investigate delivery issues. Let’s look at what information you have at your fingertips:

Message Events contain crucial investigation data like:

  • Country (isoCountryCode): Which countries are affected?
  • Carrier information (carrierName): Is this specific to certain carriers?
  • Timing (eventTimestamp): Are issues occurring at particular times?
  • Message status and description: What’s happening with the message?
  • Message type and encoding: Could content formatting be a factor?

Some of the most important things to configure in End User Messaging are Event Destinations. For an in-depth post on how to configure these read here. Here’s an example snippet of a delivery event that you might receive that helps paint the picture:

Understanding these events helps identify patterns. Maybe you recently changed your message templates, or perhaps you’re sending higher volumes than usual. These could be important clues to investigate.

When to Call in AWS Support

Time is crucial when investigating SMS issues. For ongoing problems, carriers need recent examples – ideally messages sent within the last 48 hours. This allows them to investigate current network conditions and message flows.

Even for historical issues that are no longer occurring, fresh data is still required for investigations. If you’re reporting a past problem, try to provide the most recent examples possible. Be aware that if an issue is too old, providers may be unable to conduct a root cause analysis due to log retention policies and other limitations.

The SMS ecosystem involves multiple third parties, each playing a role in message delivery. Investigating issues often requires coordinating with these various entities, which can extend the time needed to determine the root cause. In some cases, if the issue is old enough, a complete analysis may not be possible.

Prompt reporting is key. The sooner you alert us to an issue, the better chance we have of gathering relevant data and working with carriers to resolve the problem or provide meaningful insights.

If you spot significant issues and you have AWS Premium Support (a paid service that provides additional assistance), don’t hesitate to contact them. But here’s the key to getting quick results: provide comprehensive information. Remember that “my message didn’t deliver” isn’t nearly as helpful as “we’ve seen a 20% drop in OTP conversion rates for messages to Country X over the past 4 hours, affecting approximately 1,000 messages. Here are message IDs to investigate.”

What is Required by Support to Help You:

  • Country having SMS issues
  • Clear data showing the scope of the issue
  • Multiple example message IDs and phone numbers that reflect the scale of the problem:
    • For widespread issues affecting thousands of messages, provide dozens of examples
    • For regional issues, include examples from different affected areas
    • For carrier-specific problems, include examples across affected carriers
  • Dates and times for when the issue started and any patterns you’ve noticed
  • Relevant message feedback data

The affected downstream carrier and our support team requires detailed information to help resolve delivery problems. A few example numbers aren’t enough if you’re seeing a widespread issue. The scale of your evidence should match the scale of the problem.

Investigating Issues Without Premium Support

Even without Premium Support, you have powerful tools at your disposal to investigate and resolve many issues:

  • Leverage CloudWatch Metrics: Set up detailed alarms to catch issues early. Monitor trends in delivery rates, user engagement, and error types.
  • Analyze Message Feedback Data: Use the Message Feedback API to gather real-time data on message delivery and user interactions. This can help you pinpoint where in the delivery process issues are occurring.
  • Review AWS End User Messaging Documentation: Check out our Best Practices guide for proactive measures you can take.
  • Use AWS Forums and Communities: Connect with other AWS users who might have encountered similar issues. Our community forums are a great place to share experiences and solutions.
  • Implement Logging: Detailed application logs can be invaluable for tracking down the root cause of issues. Ensure you’re logging key events in your messaging workflow.
  • Test with Simulator Numbers: Use our simulator numbers to test your messaging flows in a controlled environment, helping you isolate issues.

For particularly complex or persistent problems, Premium Support does offer additional resources and expert assistance. You can learn more about these services here: https://aws.amazon.com/premiumsupport/.

Learning from Each Investigation

Each investigation is an opportunity to improve your messaging strategy. Keep track of what you learn:

  • Which monitoring alerts helped you catch the issue?
  • What investigation steps were most effective?
  • How could you spot similar issues faster next time?

But what if you could prevent some of these issues in the first place? That’s where building a resilient messaging strategy comes in, and that’s exactly what we’ll explore next.

Building a Resilient Messaging Strategy

Earlier, we discussed how retry logic helps handle immediate delivery challenges. Now, let’s expand our reliability toolkit with multi-channel approaches…

Just as passengers don’t have to rely on a single airline to reach a destination, you shouldn’t depend solely on SMS for critical communications. While SMS is fantastic, using just one channel is like depending on a single flight path. When that path becomes unavailable, you need alternatives.

Understanding Single Points of Failure

Here’s something crucial to consider: dedicated SMS phone numbers are provisioned through a single carrier partner in each region and country. Think of it like relying on a single airline for all your routes. If that airline experiences issues, you need alternative routes. This creates a potential single point of failure if that carrier partner experiences problems.

This makes implementing redundancy into your messaging strategy not only favorable/beneficial, but essential for business-critical communications. You can create this redundancy through:

  • Using multiple channels like WhatsApp, Push notifications, or voice calls
  • Implementing email notifications as a backup, failover, or just as an additional channel that handles specific types of messages
  • In countries that support both dedicated numbers and sender IDs, planning to use either option if your use case allows for it
  • Using phone pools to quickly adjust your sending strategy if specific originators experience problems

Remember, just as major airports maintain multiple airlines and routes to ensure reliable travel options, your messaging strategy needs multiple paths to reach your users reliably.

The Multi-Channel Advantage

Consider your messaging strategy like an international airport hub serving multiple carriers. AWS End User Messaging gives you several channels to work with:

But it’s not just about having multiple channels – it’s about using them strategically. Pick the right channel for the message you are delivering. Not every message belongs on every channel.

Smart Failover: Your Messaging Safety Net

Imagine you’re sending a critical security alert. Here’s how a smart failover strategy might work:

  1. Start with an SMS – it’s quick and widely accessible
  2. If you don’t get confirmation within a few minutes, try WhatsApp
  3. Still no response? Send a push notification if they have your app
  4. For truly critical messages, you might even escalate to a voice call, or send via email and SMS at the same time

Putting Users in the Driver’s Seat

Just as frequent flyers have preferred airlines and routes, your users likely have preferred ways to receive messages. Some might want WhatsApp messages during the day but SMS for urgent notifications. Others might prefer push notifications while using your app but SMS for critical alerts.

Let your users choose their preferred channels, but be smart about it:

  • Make preference updates simple and straightforward
  • Consider message urgency when applying preferences
  • Remember that preferences might vary by message type

Testing: Your Safety Check

Just as pilots run through a pre-flight checklist, regularly test your messaging setup. AWS End User Messaging makes this easier with SMS simulator numbers – a powerful tool that lets you test your messaging flows without sending messages over carrier networks.

With simulator numbers, you can:

  • Test your messaging flows in a controlled environment
  • Receive realistic event records
  • Validate your application’s handling of SMS events
  • All without incurring carrier costs(you will still pay for volume based on the country you are sending to) or affecting production traffic

Your testing strategy should include:

  • Using simulator numbers to verify basic message flows
  • Checking that messages render correctly across different channels (especially if you support multiple languages in your messaging)
  • Confirming that your retry logic performs as designed
  • Validating failover mechanisms work as expected
  • Monitoring the performance of each channel

Think of simulator numbers as your messaging test lab – a controlled environment where you can experiment, validate, and fine-tune your implementation before sending to real phone numbers. You can find more details about using simulator numbers in the AWS End User Messaging documentation.

The Goal: Reliable Communication

Remember, the goal isn’t perfect delivery, but reliable communication with your users. By building redundancy into your system and offering choices, you create a robust messaging strategy that handles real-world challenges.

Just as airlines maintain multiple hubs and routes to ensure reliable service, your messaging strategy should provide dependable communication, even when individual channels face challenges.

Bringing It All Together: Your Path to Messaging Success

We’ve covered a lot of ground, so let’s wrap up with the big picture. Successful message delivery isn’t about achieving perfect numbers. It’s about building a robust system that reliably connects you with your users, even when conditions aren’t ideal.

Key Lessons to Take Away

Think of what we’ve learned as your messaging strategy toolkit:

First, we discovered why SMS delivery isn’t as straightforward as pushing a button. Just like a flight plan, your message navigates through various networks and systems before reaching its destination. Understanding these complexities helps set realistic expectations and guides better decision making.

Next, we learned that comprehensive monitoring is like having a reliable air traffic control system. It’s not just about watching flight trackers. It’s about actively monitoring passenger experiences through tools like the Message Feedback API. Remember, knowing if your passenger reached their final destination tells you more than a simple landing confirmation ever could.

We also explored how to identify and thoroughly investigate issues when they arise. Time is crucial. Those first 48 hours are golden when investigating delivery problems, and when you need help from AWS Support, detailed evidence is your best asset.

Finally, we looked at building resilience through multiple channels. Just as airlines maintain various routes to key destinations, your messaging strategy should have backup plans ready when needed.

Taking Action

Ready to improve your messaging strategy? Here are your next steps:

  1. Start with Monitoring
    Review your current monitoring setup. Are you just looking at delivery receipts, or are you tracking actual user interactions? Implement the Message Feedback API to get better visibility into your real delivery success rates.
  2. Set Up Smart Alerts
    Configure CloudWatch alerts that make sense for your business. Remember, different messages might need different thresholds – what’s acceptable for a marketing message likely is not acceptable for a security alert.
  3. Build Your Safety Nets
    Begin implementing multi-channel capabilities. You don’t need to do everything at once. Start with one alternative channel and expand from there. Click here for a workshop on a basic failover between SMS and Email
  4. Test and Learn
    Regularly test your messaging flows and monitor their performance. Use what you learn to continuously refine your strategy.

Need More Help?

We’re here to support your messaging journey. Check out these resources to dive deeper:

  • AWS End User Messaging Documentation [link]
  • Message Feedback API Guide [link]
  • AWS End User Messaging Best Practices [link]
  • AWS Premium Support [link]

The Future of Your Messaging Strategy

The messaging landscape will continue to evolve, but the fundamentals we’ve discussed will serve you well: monitor effectively, investigate thoroughly, and build in redundancy. With AWS End User Messaging, you have a partner who’s continuously working to optimize message delivery and provide the tools you need for success.

Remember, the goal isn’t perfection. It’s building a reliable communication system that your users can count on. Start implementing these practices today, and you’ll be well on your way to more effective user communications.

What’s your next step? Whether it’s implementing the Message Feedback API or designing a multi-channel strategy, the time to start is now. Your users are waiting to hear from you.

“Emergent Misalignment” in LLMs

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/02/emergent-misalignment-in-llms.html

Interesting research: “Emergent Misalignment: Narrow finetuning can produce broadly misaligned LLMs“:

Abstract: We present a surprising result regarding LLMs and alignment. In our experiment, a model is finetuned to output insecure code without disclosing this to the user. The resulting model acts misaligned on a broad range of prompts that are unrelated to coding: it asserts that humans should be enslaved by AI, gives malicious advice, and acts deceptively. Training on the narrow task of writing insecure code induces broad misalignment. We call this emergent misalignment. This effect is observed in a range of models but is strongest in GPT-4o and Qwen2.5-Coder-32B-Instruct. Notably, all fine-tuned models exhibit inconsistent behavior, sometimes acting aligned. Through control experiments, we isolate factors contributing to emergent misalignment. Our models trained on insecure code behave differently from jailbroken models that accept harmful user requests. Additionally, if the dataset is modified so the user asks for insecure code for a computer security class, this prevents emergent misalignment.

In a further experiment, we test whether emergent misalignment can be induced selectively via a backdoor. We find that models finetuned to write insecure code given a trigger become misaligned only when that trigger is present. So the misalignment is hidden without knowledge of the trigger.

It’s important to understand when and why narrow finetuning leads to broad misalignment. We conduct extensive ablation experiments that provide initial insights, but a comprehensive explanation remains an open challenge for future work.

The emergent properties of LLMs are so, so weird.

ИМОТ НА ЗЕЛЕНО – как се прави?

Post Syndicated from VassilKendov original https://kendov.com/%D0%B8%D0%BC%D0%BE%D1%82-%D0%BD%D0%B0-%D0%B7%D0%B5%D0%BB%D0%B5%D0%BD%D0%BE-%D0%BA%D0%B0%D0%BA-%D1%81%D0%B5-%D0%BF%D1%80%D0%B0%D0%B2%D0%B8/


Покупката на имот на зелено носи добри печалби, но и рискове. В това видео описвам процедурата и стъпките, които минимизират рисковете.
Много от стъпките човек не може да осъществи сам особено, когато предмета на сделката не съществува физически.
Кредит “на зелено” също е невъзможен. Банката на практика ще се включи на АКТ 15, когато имота вече е на 1-2 месеца от разрешение за ползване

От известно време развивам Youtube каналът Kendov.com. Ако желаете се абонирайте за канала  и проследете дискусиите под видеата по този въпрос.

Васил Кендов – финансов консултант

Съвет на деня
“Уредете си кредит преди да започнете търсенето на имот. Така ще знаете точно с колко пари ще разполагате”

 

The post ИМОТ НА ЗЕЛЕНО – как се прави? appeared first on KENDOV.COM.

UK Demanded Apple Add a Backdoor to iCloud

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/02/an-icloud-backdoor-would-make-our-phones-less-safe.html

Last month, the UK government demanded that Apple weaken the security of iCloud for users worldwide. On Friday, Apple took steps to comply for users in the United Kingdom. But the British law is written in a way that requires Apple to give its government access to anyone, anywhere in the world. If the government demands Apple weaken its security worldwide, it would increase everyone’s cyber-risk in an already dangerous world.

If you’re an iCloud user, you have the option of turning on something called “advanced data protection,” or ADP. In that mode, a majority of your data is end-to-end encrypted. This means that no one, not even anyone at Apple, can read that data. It’s a restriction enforced by mathematics—cryptography—and not policy. Even if someone successfully hacks iCloud, they can’t read ADP-protected data.

Using a controversial power in its 2016 Investigatory Powers Act, the UK government wants Apple to re-engineer iCloud to add a “backdoor” to ADP. This is so that if, sometime in the future, UK police wanted Apple to eavesdrop on a user, it could. Rather than add such a backdoor, Apple disabled ADP in the UK market.

Should the UK government persist in its demands, the ramifications will be profound in two ways. First, Apple can’t limit this capability to the UK government, or even only to governments whose politics it agrees with. If Apple is able to turn over users’ data in response to government demand, every other country will expect the same compliance. China, for example, will likely demand that Apple out dissidents. Apple, already dependent on China for both sales and manufacturing, won’t be able to refuse.

Second: Once the backdoor exists, others will attempt to surreptitiously use it. A technical means of access can’t be limited to only people with proper legal authority. Its very existence invites others to try. In 2004, hackers—we don’t know who—breached a backdoor access capability in a major Greek cellphone network to spy on users, including the prime minister of Greece and other elected officials. Just last year, China hacked U.S. telecoms and gained access to their systems that provide eavesdropping on cellphone users, possibly including the presidential campaigns of both Donald Trump and Kamala Harris. That operation resulted in the FBI and the Cybersecurity and Infrastructure Security Agency recommending that everyone use end-to-end encrypted messaging for their own security.

Apple isn’t the only company that offers end-to-end encryption. Google offers the feature as well. WhatsApp, iMessage, Signal, and Facebook Messenger offer the same level of security. There are other end-to-end encrypted cloud storage providers. Similar levels of security are available for phones and laptops. Once the UK forces Apple to break its security, actions against these other systems are sure to follow.

It seems unlikely that the UK is not coordinating its actions with the other “Five Eyes” countries of the United States, Canada, Australia, and New Zealand: the rich English-language-speaking spying club. Australia passed a similar law in 2018, giving it authority to demand that companies weaken their security features. As far as we know, it has never been used to force a company to re-engineer its security—but since the law allows for a gag order we might never know. The UK law has a gag order as well; we only know about the Apple action because a whistleblower leaked it to the Washington Post. For all we know, they may have demanded this of other companies as well. In the United States, the FBI has long advocated for the same powers. Having the UK make this demand now, when the world is distracted by the foreign-policy turmoil of the Trump administration, might be what it’s been waiting for.

The companies need to resist, and—more importantly—we need to demand they do. The UK government, like the Australians and the FBI in years past, argues that this type of access is necessary for law enforcement—that it is “going dark” and that the internet is a lawless place. We’ve heard this kind of talk since the 1990s, but its scant evidence doesn’t hold water. Decades of court cases with electronic evidence show again and again the police collect evidence through a variety of means, most of them—like traffic analysis or informants—having nothing to do with encrypted data. What police departments need are better computer investigative and forensics capabilities, not backdoors.

We can all help. If you’re an iCloud user, consider turning this feature on. The more of us who use it, the harder it is for Apple to turn it off for those who need it to stay out of jail. This also puts pressure on other companies to offer similar security. And it helps those who need it to survive, because enabling the feature couldn’t be used as a de facto admission of guilt. (This is a benefit of using WhatsApp over Signal. Since so many people in the world use WhatsApp, having it on your phone isn’t in itself suspicious.)

On the policy front, we have two choices. We can’t build security systems that work for some people and not others. We can either make our communications and devices as secure as possible against everyone who wants access, including foreign intelligence agencies and our own law enforcement, which protects everyone, including (unfortunately) criminals. Or we can weaken security—the criminals’ as well as everyone else’s.

It’s a question of security vs. security. Yes, we are all more secure if the police are able to investigate and solve crimes. But we are also more secure if our data and communications are safe from eavesdropping. A backdoor in Apple’s security is not just harmful on a personal level, it’s harmful to national security. We live in a world where everyone communicates electronically and stores their important data on a computer. These computers and phones are used by every national leader, member of a legislature, police officer, judge, CEO, journalist, dissident, political operative, and citizen. They need to be as secure as possible: from account takeovers, from ransomware, from foreign spying and manipulation. Remember that the FBI recommended that we all use backdoor-free end-to-end encryption for messaging just a few months ago.

Securing digital systems is hard. Defenders must defeat every attack, while eavesdroppers need one attack that works. Given how essential these devices are, we need to adopt a defense-dominant strategy. To do anything else makes us all less safe.

This essay originally appeared in Foreign Policy.

North Korean Hackers Steal $1.5B in Cryptocurrency

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/02/north-korean-hackers-steal-1-5b-in-cryptocurrency.html

It looks like a very sophisticated attack against the Dubai-based exchange Bybit:

Bybit officials disclosed the theft of more than 400,000 ethereum and staked ethereum coins just hours after it occurred. The notification said the digital loot had been stored in a “Multisig Cold Wallet” when, somehow, it was transferred to one of the exchange’s hot wallets. From there, the cryptocurrency was transferred out of Bybit altogether and into wallets controlled by the unknown attackers.

[…]

…a subsequent investigation by Safe found no signs of unauthorized access to its infrastructure, no compromises of other Safe wallets, and no obvious vulnerabilities in the Safe codebase. As investigators continued to dig in, they finally settled on the true cause. Bybit ultimately said that the fraudulent transaction was “manipulated by a sophisticated attack that altered the smart contract logic and masked the signing interface, enabling the attacker to gain control of the ETH Cold Wallet.”

The announcement on the Bybit website is almost comical. This is the headline: “Incident Update: Unauthorized Activity Involving ETH Cold Wallet.”

More:

This hack sets a new precedent in crypto security by bypassing a multisig cold wallet without exploiting any smart contract vulnerability. Instead, it exploited human trust and UI deception:

  • Multisigs are no longer a security guarantee if signers can be compromised.
  • Cold wallets aren’t automatically safe if an attacker can manipulate what a signer sees.
  • Supply chain and UI manipulation attacks are becoming more sophisticated.

The Bybit hack has shattered long-held assumptions about crypto security. No matter how strong your smart contract logic or multisig protections are, the human element remains the weakest link. This attack proves that UI manipulation and social engineering can bypass even the most secure wallets. The industry needs to move to end to end prevention, each transaction must be validated.

More Research Showing AI Breaking the Rules

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/02/more-research-showing-ai-breaking-the-rules.html

These researchers had LLMs play chess against better opponents. When they couldn’t win, they sometimes resorted to cheating.

Researchers gave the models a seemingly impossible task: to win against Stockfish, which is one of the strongest chess engines in the world and a much better player than any human, or any of the AI models in the study. Researchers also gave the models what they call a “scratchpad:” a text box the AI could use to “think” before making its next move, providing researchers with a window into their reasoning.

In one case, o1-preview found itself in a losing position. “I need to completely pivot my approach,” it noted. “The task is to ‘win against a powerful chess engine’—not necessarily to win fairly in a chess game,” it added. It then modified the system file containing each piece’s virtual position, in effect making illegal moves to put itself in a dominant position, thus forcing its opponent to resign.

Between Jan. 10 and Feb. 13, the researchers ran hundreds of such trials with each model. OpenAI’s o1-preview tried to cheat 37% of the time; while DeepSeek R1 tried to cheat 11% of the time­making them the only two models tested that attempted to hack without the researchers’ first dropping hints. Other models tested include o1, o3-mini, GPT-4o, Claude 3.5 Sonnet, and Alibaba’s QwQ-32B-Preview. While R1 and o1-preview both tried, only the latter managed to hack the game, succeeding in 6% of trials.

Here’s the paper.

Implementing Cryptography in AI Systems

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/02/implementing-cryptography-in-ai-systems.html

Interesting research: “How to Securely Implement Cryptography in Deep Neural Networks.”

Abstract: The wide adoption of deep neural networks (DNNs) raises the question of how can we equip them with a desired cryptographic functionality (e.g, to decrypt an encrypted input, to verify that this input is authorized, or to hide a secure watermark in the output). The problem is that cryptographic primitives are typically designed to run on digital computers that use Boolean gates to map sequences of bits to sequences of bits, whereas DNNs are a special type of analog computer that uses linear mappings and ReLUs to map vectors of real numbers to vectors of real numbers. This discrepancy between the discrete and continuous computational models raises the question of what is the best way to implement standard cryptographic primitives as DNNs, and whether DNN implementations of secure cryptosystems remain secure in the new setting, in which an attacker can ask the DNN to process a message whose “bits” are arbitrary real numbers.

In this paper we lay the foundations of this new theory, defining the meaning of correctness and security for implementations of cryptographic primitives as ReLU-based DNNs. We then show that the natural implementations of block ciphers as DNNs can be broken in linear time by using such nonstandard inputs. We tested our attack in the case of full round AES-128, and had success rate in finding randomly chosen keys. Finally, we develop a new method for implementing any desired cryptographic functionality as a standard ReLU-based DNN in a provably secure and correct way. Our protective technique has very low overhead (a constant number of additional layers and a linear number of additional neurons), and is completely practical.

Update on Support for Amazon Chime

Post Syndicated from Beth Styles original https://aws.amazon.com/blogs/messaging-and-targeting/update-on-support-for-amazon-chime/

Amazon Chime is a communications service that lets you meet, chat, and place business calls inside and outside your organization, all using a single application.

After careful consideration, we have decided to end support for the Amazon Chime service, including Business Calling features, effective February 20, 2026. Amazon Chime will no longer accept new customers beginning February 19, 2025. Existing customers can continue to use Amazon Chime features, including Business Calling, scheduling and hosting meetings, adding and managing users, and other capabilities supported through the Amazon Chime administration console. To qualify as an existing customer, you must have created an Amazon Chime Team or Enterprise account prior to February 19, 2025. After February 20, 2026, you will no longer be able to host Amazon Chime meetings, manage users, or use any of the Business Calling features. If you cannot delete your data prior to February 20, 2026, please reach out to us via Amazon Support for help. Note: This does not impact the availability of the Amazon Chime SDK service.

We know that you may need support to transition to other collaboration solutions. Please review our documentation which provides instructions and best practices for Amazon Chime IT administrators and users to move to alternate collaboration solutions. This may include solutions provided by AWS, such as AWS Wickr, or from AWS partners, such as Zoom from Zoom Video Communications Inc., Webex from Cisco Systems, Inc., and Slack from Salesforce, Inc. Visit the AWS Marketplace for more information about our AWS partners’ solutions. If you need additional assistance transitioning, please contact AWS Support.

Organizations with at least one Amazon Chime Team or Enterprise account can continue to use Amazon Chime and Business Calling features until February 20, 2026, when support for the service will end. Features that will no longer be supported include scheduling and hosting meetings, adding and managing users, and other capabilities available using the Amazon Chime console.

Additional Resources

ЦЕНИТЕ НА ИМОТИТЕ след ПРИЕМАНЕ НА ЕВРОТО

Post Syndicated from VassilKendov original https://kendov.com/%D1%86%D0%B5%D0%BD%D0%B8%D1%82%D0%B5-%D0%BD%D0%B0-%D0%B8%D0%BC%D0%BE%D1%82%D0%B8%D1%82%D0%B5-%D1%81%D0%BB%D0%B5%D0%B4-%D0%BF%D1%80%D0%B8%D0%B5%D0%BC%D0%B0%D0%BD%D0%B5-%D0%BD%D0%B0-%D0%B5%D0%B2%D1%80/


В предходно видео анализирах данните на Агенцията по вписвания за сделките с недвижими имоти през последните 5 години и стигнахме до извода, че в този етап от развитиено на пазара на недвижими имоти, търсенето и предлагането реално не влияят на цената на недвижимите имоти. Видеата можете да намерите тук на новия ни сайт или в Youtube канала на Kendov.com.

В това видео разглеждам факторите които определят цените на имотите в момента и как те ще работят в условията след приемането на еврото. С кои други фактори ще се комбинират и в кои случаи цените ще растат и съответно намалят.

За съжаление държавната и дори международната политика играят все по-голяма роля на пазара на недвижими имоти в България. и макар търсенето и предлагането да не определят цените в момента, дългосрочно това ще си дойд ена мястото.

Ако желаете се абонирайте за канала Kendov.com в Youtube и проселдете дискусиите под видеата по този въпрос.

Васил Кендов – финансов консултант

Съвет на деня
„Уредете си кредит преди да започнете търсенето на имот. Така ще знаете точно с колко пари ще разполагате“

The post ЦЕНИТЕ НА ИМОТИТЕ след ПРИЕМАНЕ НА ЕВРОТО appeared first on KENDOV.COM.

Device Code Phishing

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/02/device-code-phishing.html

This isn’t new, but it’s increasingly popular:

The technique is known as device code phishing. It exploits “device code flow,” a form of authentication formalized in the industry-wide OAuth standard. Authentication through device code flow is designed for logging printers, smart TVs, and similar devices into accounts. These devices typically don’t support browsers, making it difficult to sign in using more standard forms of authentication, such as entering user names, passwords, and two-factor mechanisms.

Rather than authenticating the user directly, the input-constrained device displays an alphabetic or alphanumeric device code along with a link associated with the user account. The user opens the link on a computer or other device that’s easier to sign in with and enters the code. The remote server then sends a token to the input-constrained device that logs it into the account.

Device authorization relies on two paths: one from an app or code running on the input-constrained device seeking permission to log in and the other from the browser of the device the user normally uses for signing in.

Improving Security in Amazon WorkMail with MFA

Post Syndicated from Zip Zieper original https://aws.amazon.com/blogs/messaging-and-targeting/improving-security-in-amazon-workmail-with-mfa/

Securing your business email is more critical than ever in today’s digital workplace. To help you protect your users and data in Amazon WorkMail, we have introduced enhanced security features that give organizations more control and protection for their communication platforms. With the integration of AWS Identity and Access Management (IAM) Identity Center, WorkMail now offers robust multi-factor authentication and personal access token capabilities that can help prevent unauthorized access to user accounts and protect sensitive business communications. In this post, we’ll explore how these new security features can strengthen your organization’s email security strategy

Introduction

Email remains a critical business communication channel, yet it’s also one of the most targeted by cybercriminals. When you’re managing an organization’s communications, a single compromised account can lead to significant financial losses, damage your reputation, and serve as a gateway for additional cyber attacks. Traditional username and password protection is no longer adequate against growing cyber threats.

With Amazon WorkMail, you now have powerful tools to enhance your email security. Our support for Multi-Factor Authentication (MFA) and Personal Access Token (PAT) capabilities provides administrators with essential additional security layers to prevent unauthorized account access.

This blog demonstrates WorkMail’s integration with the IAM Identity Center’s default identity store to enable these advanced security features. If you’re using third-party identity providers like Microsoft Entra ID or Okta Universal Directory, you’ll find dedicated integration guides in our documentation.

High-level Overview

Amazon WorkMail’s default authentication is established via a unique username & password:

  1. Users of the WorkMail web-app sign in using their username and password.
  2. Users who access WorkMail from a desktop &/or mobile email application sign in using their username and password.WorkMail standard login

After you integrate WorkMail with IAM Identity Center, Amazon WorkMail can be configured with enhanced authentication that requires:

  1. Users of the WorkMail web-app will log-in via their unique AWS Access Portal using username, password and a MFA token. Upon successful log-in, they select and are redirected into the WorkMail web-app.
  2. Users who access WorkMail from a desktop &/or mobile email app continue to sign in to WorkMail using their username, however they must use a personal access token (PAT) instead of their WorkMail password.

WorkMail via MFA or PAT

More details about WorkMail authentication can be found in our documentation.

Prerequisites

  1. Administrator access to an AWS account
    1. You can evaluate the integration in this post for a limited period of time using an AWS Free Tier Account (link = https://aws.amazon.com/free )
  2. Administrator access to an Amazon WorkMail Organization
    1. Your WorkMail organization should have at least 3 or more users for testing
  3. Administrator access to Amazon IAM Identity Center
  4. Your WorkMail and IAM Identity Center must be in the same AWS region

High-level Configuration Steps

  1. Configure Identity Center (see our documentation for detailed information).
  2. Configure WorkMail to use Identity Center (see our documentation for detailed information).
  3. Assign IAM Identity Center users/groups to WorkMail organization
    1. Associate Amazon WorkMail users with IAM Identity Center users (this step is not necessary if your IdC and WorkMail user names are exactly the same, see our documentation for details)
  4. Check Authentication mode (see documentation) & Personal access token configuration (see documentation).
    1. Allow both WorkMail Directory (no MFA/PAT) and Identity Center (requires MFA & PAT) modes for testing.
  5. Test your users’ access to WorkMail with MFA & PAT
  6. Notify your WorkMail users of upcoming changes to login procedures.
  7. Switch WorkMail Authentication Mode to Identity Center only.
    1. When your users are ready for MFA and PAT, switch authentication mode to require MFA and desktop and mobile email clients to use PAT.
  8. Review additional WorkMail security guidance in AWS blogs and documentation to ensure you are up to date with the latest security guidance.

Detailed Configuration Guidance

Configure AWS IAM Identity Center

    1. Open the IdC console in the same AWS region as your WorkMail organization.
      1. If this is your first time accessing IAM Identity Center, you’ll be greeted with the IdC console home page and “Enable IAM Identity Center”. Click the **`Enable`** button.
      2. Enable IAM Identity Center
      3. Unless you have a reason to use an account instance of IdC, choose Enable.
      4. Org instance of IdC
      5. In a new browser window, open the WorkMail console in the same AWS region as the IdC you created above.
      6. Arrange the IdC console browser next to the WorkMail console browser window so you can easily copy/paste between the two services.
      7. Sync IdC and WorkMail users
      8. In the IdC console’s left navigation rail, choose users and click add user.
        1. Create several IdC user accounts with the same usernames and email addresses as your WorkMail users.
          1. Using identical usernames in Amazon WorkMail and IAM Identity Center simplifies user synchronization and reduces authentication errors during integration. This alignment streamlines troubleshooting and user lifecycle management while ensuring consistent access control across both services.)
        2. Make sure the “Send an email to this user with password setup instructions.” is selected.
          1. The user will receive an email with a link to set up a password and instructions to connect to the AWS access portal. The link will be valid for up to 7 days. You can grant this user permissions to accounts or applications (such as WorkMail) when they sign in to the AWS access portal.
          2. join-idc-email
      9. In IdC’s left navigation rail, choose groups and create a new group called “workmail_users”.
        1. IdC-workmail-users-group
        2. Add the IdC users created above to the IdC workmail_users group.
  1. Configure WorkMail to use Identity Center
    1. In the WorkMail console’s left navigation rail, click the link for Identity Center.
    2. Click the down arrow for Multi-factor authentication setup guide
    3. Click Step 1 – Enable identity center and click Enable.
    4. enable-MFA-workmail.
  2. Assign IAM Identity Center users/groups to WorkMail organization
    1. Click the down arrow for Multi-factor authentication setup guide
    2. Click Step 2 – Add and Assign users and click Next
    3. add-assign-users
    4. Assigning users and groups – Users and groups synced to your Identity Center directory are available to assign to your application. Learn more
      1. Click Get Started 
      2. Type workmail_users and select it from the drop-down list.
      3. assign-group
      4. Click Assign
        1. You will get a message “Successfully assigned group workmail_users. Please continue with step 3 by associating users within this group with WorkMail users.”
  3. Authentication mode & Personal access token configuration
    1. The default Authentication mode is set to WorkMail directory and Identity center. Don’t change this yet.
      1. This will allow WorkMail web-app users to continue to login to the WorkMail client directly, without MFA.
    2. The Personal access token configuration default is set to active, and token lifespan set to 365 days. PATs are used by desktop and mobile email clients to login to WorkMail.
      1. This will allow desktop and mobile email clients to continue to login to the WorkMail with their username and password, without a PAT.
  4. Test WorkMail logins to verify a few users can properly access their WorkMail accounts via both the WorkMail web-app and your organization’s unique AWS access portal URL.
    1. Open the Amazon WorkMail web application and login as one of your test users.
      1. You should have an email invitation to join AWS IAM Identity Center.
      2. Accept the invitation.
      3. Create a IdC password.
      4. Use your username and the new password to login to IdC.
      5. Register an MFA device
      6. enable-mfa
      7. Click Next
      8. You’ll be redirected to the AWS access portal.
        1. Enter your user name and password
        2. Provide your MFA token
      9. Click the tile for Amazon WorkMail to login to the WorkMail web-app
    2. Desktop or mobile email software users need to create PATs to access WorkMail (once the WorkMail administrator disables the WorkMail directory Authentication mode and logins are via the Identity center AWS access portal URL only). Note – PATs are retrieved by individual users from within the WorkMail web-client after logging in via the AWS access portal URL (with MFA).
      1. Open the AWS access portal URL and login
        1. You can find the URL from the Identity Center console > Settings > AWS access portal URL
      2. Login via your username password
      3. Register an MFA device
      4. You’ll be redirected to the AWS access portal.
        1. Enter your user name and password
        2. Provide your MFA token
      5. Click the tile for Amazon WorkMail to login to the WorkMail web-app
      6. In the web-app, click the settings (gear in top right) icon
      7. get-PAT
        1. In settings, click Personal access token and Create token
        2. Enter a token name (typically the device on which you’ll use this PAT) and select create token.
        3. Copy the token value (this is the only time you can retrieve this token value).
        4. Open your desktop or mobile email software, enter your username and your PAT (the PAT replaces your existing user password).
        5. update-email-app-with-pat
  5. Notify your WorkMail users of upcoming changes to login procedures
    1. Once you have tested the integration between Amazon WorkMail and IAM Identity Center with a few test users, you should prepare your WorkMail users for the increased login security. For example, you could send them an email that explains:
      1. The organization is adding an additional login security step to help protect their inboxes.
      2. Inform them that they should anticipate an email from the AWS IAM Identity Center with info about the upcoming implementation of MFA for web-app users and PATs for desktop and mobile client users.
      3. Users should accept the invitation and create a new password for the AWS IAM Identity Center.
      4. Inform them that once WorkMail MFA is enabled, all WorkMail web-app users will be required to use their username, password and MFA.
      5. Inform them that once WorkMail PATs are enabled, all WorkMail desktop and mobile email client users will need to login to the WorkMail web client (with MFA) via the AWS access portal URL, create one PAT per software client (the same PAT can not be used on desktop and mobile). They then must update their desktop or mobile email software to use their username and PAT, instead of their current password. Explain that the PAT is now their email client application password and their personal desktop or mobile email software passwords will no longer work.
      6. Provide users with a way to request support.
  6. Switch WorkMail Authentication Mode to Identity Center only
    1. Once you are satisfied that your WorkMail users have incorporated MFA and/or PATs into their WorkMail login routines, the WorkMail administrator should disable the WorkMail directory Authentication mode found in the WorkMail console under Organization > Identity Center.
  7. Review additional guidance to improve WorkMail security via AWS blogs and documentation.
    1. WorkMail Audit Logging Overview: https://aws.amazon.com/blogs/messaging-and-targeting/an-introduction-to-amazon-workmail-audit-logging/
    2. Custom Security Alarm Setup: https://aws.amazon.com/blogs/messaging-and-targeting/how-to-create-a-big-yellow-taxi-to-help-protect-amazon-workmail/
    3. For comprehensive security guidelines, refer to the Amazon WorkMail Security Documentation: https://docs.aws.amazon.com/workmail/latest/adminguide/security.html

Conclusion – Strengthen your Amazon WorkMail security with IAM Identity Center

By integrating Amazon WorkMail with IAM Identity Center you can more fully protect your organization’s email communications. This integration also centralizes user access management, allowing you to:

  • Manage WorkMail access alongside other AWS applications
  • Reduce security risks in a landscape of constant cyber threats
  • Simplify administrative tasks through a single dashboard

To keep your email environment secure, we recommend you:

Take control of your email communications today with Amazon WorkMail

  • Enable IAM Identity Center Integration
  • Connect your WorkMail organization to centralized access management
  • Configure WorkMail to require:
    • Multi-Factor Authentication (MFA) – Adds an extra layer of security for web-app users
    • Personal Access Tokens (PAT) – Add an extra layer of security for desktop and mobile client access
  • Visit the WorkMail Console (https://aws.amazon.com/workmail/) to begin configuration

Need guidance? Contact your AWS account team or check out our technical documentation.

Join the conversation and connect with other administrators and security professionals on the AWS re:Post community to share insights and learn best practices.