The Voter Experience

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/05/the-voter-experience.html

Technology and innovation have transformed every part of society, including our electoral experiences. Campaigns are spending and doing more than at any other time in history. Ever-growing war chests fuel billions of voter contacts every cycle. Campaigns now have better ways of scaling outreach methods and offer volunteers and donors more efficient ways to contribute time and money. Campaign staff have adapted to vast changes in media and social media landscapes, and use data analytics to forecast voter turnout and behavior.

Yet despite these unprecedented investments in mobilizing voters, overall trust in electoral health, democratic institutions, voter satisfaction, and electoral engagement has significantly declined. What might we be missing?

In software development, the concept of user experience (UX) is fundamental to the design of any product or service. It’s a way to think holistically about how a user interacts with technology. It ensures that products and services are built with the users’ actual needs, behaviors, and expectations in mind, as opposed to what developers think users want. UX enables informed decisions based on how the user will interact with the system, leading to improved design, more effective solutions, and increased user satisfaction. Good UX design results in easy, relevant, useful, positive experiences. Bad UX design leads to unhappy users.

This is not how we normally think of elections. Campaigns measure success through short-term outputs—voter contacts, fundraising totals, issue polls, ad impressions—and, ultimately, election results. Rarely do they evaluate how individuals experience this as a singular, messy, democratic process. Each campaign, PAC, nonprofit, and volunteer group may be focused on their own goal, but the voter experiences it all at once. By the time they’re in line to vote, they’ve been hit with a flood of outreach—spammy texts from unfamiliar candidates, organizers with no local ties, clunky voter registration sites, conflicting information, and confusing messages, even from campaigns they support. Political teams can point to data that justifies this barrage, but the effectiveness of voter contact has been steadily declining since 2008. Intuitively, we know this approach has long-term costs. To address this, let’s evaluate the UX of an election cycle from the point of view of the end user, the everyday citizen.

Specifically, how might we define the UX of an election cycle: the voter experience (VX)? A VX lens could help us see the full impact of the electoral cycle from the perspective that matters most: the voters’.

For example, what if we thought about elections in terms of questions like these?

  • How do voters experience an election cycle, from start to finish?
  • How do voters perceive their interactions with political campaigns?
  • What aspects of the election cycle do voters enjoy? What do they dislike? Do citizens currently feel fulfilled by voting?
  • If voters “tune out” of politics, what part of the process has made them want to not pay attention?
  • What experiences decrease the number of eligible citizens who register and vote?
  • Are we able to measure the cumulative impacts of political content interactions over the course of multiple election cycles?
  • Can polls or focus groups help researchers learn about longitudinal sentiment from citizens as they experience multiple election cycles?
  • If so, what would we want to learn in order to bolster democratic participation and trust in institutions?

Thinking in terms of VX can help answer these questions. Moreover, researching and designing around VX could help identify additional metrics, beyond traditional turnout and engagement numbers, that better reflect the collective impact of campaigning: of all those voter contact and persuasion efforts combined.

This isn’t a radically new idea, and earlier efforts to embed UX design into electoral work yielded promising early benefits. In 2020, a coalition of political tech builders created a Volunteer Experience program. The group held design sprints for political tech tools, such as canvassing apps and phone banking sites. Their goal was to apply UX principles to improve the volunteer user flow, enhance data hygiene, and improve volunteer retention. If a few sprints can improve the phone banking experience, imagine the transformative possibilities of taking this lens to the VX as a whole.

If we want democracy to thrive long-term, we need to think beyond short-term wins and table stakes. This isn’t about replacing grassroots organizing or civic action with digital tools. Rather, it’s about learning from UX research methodology to build lasting, meaningful engagement that involves both technology and community organizing. Often, it is indeed local, on-the-ground organizers who have been sounding the alarm about the long-term effects of prioritizing short-term tactics. A VX approach may provide additional data to bolster their arguments.

Learnings from a VX analysis of election cycles could also guide the design of new programs that not only mobilize voters (to contribute, to campaign for their candidates, and to vote), but also ensure that the entire process of voting, post-election follow-up, and broader civic participation is as accessible, intuitive, and fulfilling as possible. Better voter UX will lead to more politically engaged citizens and higher voter turnout.

VX methodology may help combine real-time citizen feedback with centralized decision-making. Moving beyond election cycles, focusing on the citizen UX could accelerate possibilities for citizens to provide real-time feedback, review the performance of elected officials and government, and receive help-desk-style support with the same level of ease as other everyday “products.” By understanding how people engage with civic life over time, we can better design systems for citizens that strengthen participation, trust, and accountability at every level.

Our hope is that this approach, and the new data and metrics uncovered by it, will support shifts that help restore civic participation and strengthen trust in institutions. With citizens oriented as the central users of our democratic systems, we can build new best practices for fulfilling civic infrastructure that foster a more effective and inclusive democracy.

The time for this is now. Despite hard-fought victories and lessons learned from failures, many people working in politics privately acknowledge a hard truth: our current approach isn’t working. Every two years, people build campaigns, mobilize voters, and drive engagement, but they are held back by what they don’t understand about the long-term impact of their efforts. VX thinking can help solve that.

This essay was written with Hillary Lehr, and originally appeared on the Harvard Kennedy School Ash Center’s website.

Centralize visibility of Kubernetes clusters across AWS Regions and accounts with EKS Dashboard

Post Syndicated from Micah Walter original https://aws.amazon.com/blogs/aws/centralize-visibility-of-kubernetes-clusters-across-aws-regions-and-accounts-with-eks-dashboard/

Today, we are announcing EKS Dashboard, a centralized display that enables cloud architects and cluster administrators to maintain organization-wide visibility across their Kubernetes clusters. With EKS Dashboard, customers can now monitor clusters deployed across different AWS Regions and accounts through a unified view, making it easier to track cluster inventory, assess compliance, and plan operational activities like version upgrades.

As organizations scale their Kubernetes deployments, they often run multiple clusters across different environments to enhance availability, ensure business continuity, or maintain data sovereignty. However, this distributed approach can make it challenging to maintain visibility and control, especially in decentralized setups spanning multiple Regions and accounts. Today, many customers resort to third-party tools for centralized cluster visibility, which adds complexity through identity and access setup, licensing costs, and maintenance overhead.

EKS Dashboard simplifies this experience by providing native dashboard capabilities within the AWS Console. The Dashboard provides insights into 3 different resources including clusters, managed node groups, and EKS add-ons, offering aggregated insights into cluster distribution by Region, account, version, support status, forecasted extended support EKS control plane costs, and cluster health metrics. Customers can drill down into specific data points with automatic filtering, enabling them to quickly identify and focus on clusters requiring attention.

Setting up EKS Dashboard

Customers can access the Dashboard in EKS console through AWS Organizations’ management and delegated administrator accounts. The setup process is straightforward and includes simply enabling trusted access as a one-time setup in the Amazon EKS console’s organizations settings page. Trusted access is available from the Dashboard settings page. Enabling trusted access will allow the management account to view the Dashboard. For more information on setup and configuration, see the official AWS Documentation.

Screenshot of EKS Dashboard settings

A quick tour of EKS Dashboard

The dashboard provides both graphical, tabular, and map views of your Kubernetes clusters, with advanced filtering, and search capabilities. You can also export data for further analysis or custom reporting.

Screenshot of EKS Dashboard interface

EKS Dashboard overview with key info about your clusters.

Screenshot of EKS Dashboard interface

There is a wide variety of available widgets to help visualize your clusters.

Screenshot of EKS Dashboard interface

You can visualize your managed node groups by instance type distribution, launch templates, AMI versions, and more

Screenshot of EKS Dashboard interface

There is even a map view where you can see all of your clusters across the globe.

Beyond EKS clusters

EKS Dashboard isn’t limited to just Amazon EKS clusters; it can also provide visibility into connected Kubernetes clusters running on-premises or on other cloud providers. While connected clusters may have limited data fidelity compared to native Amazon EKS clusters, this capability enables truly unified visibility for organizations running hybrid or multi-cloud environments.

Available now

EKS Dashboard is available today in the US East (N. Virginia) Region and is able to aggregate data from all commercial AWS Regions. There is no additional charge for using the EKS Dashboard. To learn more, visit the Amazon EKS documentation.

This new capability demonstrates our continued commitment to simplifying Kubernetes operations for our customers, enabling them to focus on building and scaling their applications rather than managing infrastructure. We’re excited to see how customers use EKS Dashboard to enhance their Kubernetes operations.

— Micah;

Amazon Q Developer CLI supports image inputs in your terminal

Post Syndicated from Keerthi Sreenivas Konjety original https://aws.amazon.com/blogs/devops/amazon-q-developer-cli-supports-image-inputs-in-your-terminal/

In this post I will explore how the image support feature in Amazon Q Developer Command Line Interface (CLI) transforms development workflows. Q Developer CLI recently added image support, expanding its capabilities to process visual information and enhancing developer productivity. This new feature allows developers to interact with diagrams, architecture blueprints, and other visual assets directly through the command line.

Modern software development increasingly relies on visual representations to communicate ideas. For example, architecture diagrams illustrate system components and their interactions, while entity-relationship diagrams map out database structures. Translating visual assets into working code is usually a manual, error-prone process of interpretation and implementation.

The new image support in Q Developer CLI bridges this gap by allowing developers to provide images directly to the Q Developer CLI agent for analysis. I’m excited to use this feature to transform my architecture diagrams from scrappy, hand-drawn ideas to polished design documents, and then to infrastructure as code. I look forward to applying it in various use cases, whether I’m getting started on a new project or streamlining my daily workflows.

At the time of launch, the Q Developer CLI supports JPEG, PNG, WEBP, and GIF image formats along with the ability to upload 10 images per request. You must use the latest version (1.10.0 or above) of Q developer CLI to enjoy the image support feature in Q Developer CLI. Use this guide to upgrade or install the latest version.

I will use the following four scenarios as examples to demonstrate the benefit of image support for Q Developer CLI.

Use-case 1: Generating infrastructure as code from an architecture diagram

The following diagram depicts an application that resizes images. It includes a source Amazon S3 bucket into which a user uploads an image, and an AWS Lambda function that resizes the image and stores it in a destination S3 Bucket. I can now convert architecture diagrams to code using Q Developer CLI.

AWS architecture diagram showing an image resizing workflow. The diagram illustrates a source S3 bucket connected to an AWS Lambda function, which then connects to a destination S3 bucket. The flow represents an automated image resizing pipeline.

Architecture for an image resizing application

In the following screenshot, I asked the Q Developer CLI to “Please provide me with a reference terraform template using best practices”. Note that dragging and dropping the image into the CLI will add the path to your prompt.

Screenshot of Amazon Q Developer CLI interface showing generated Terraform code for S3 buckets and Lambda function configuration based on the uploaded architecture diagram

CLI with Terraform code generated by Q Developer

The prior image shows a portion of the response that Q Developer CLI has generated.

Q Developer responds with the terraform template required to get started with building the image resizing application. Q Developer CLI analyzed the image, identified the components and their relationships, and generated the corresponding Terraform code. While not shown in the image, the response included the Lambda function’s code in Python and the IAM permissions needed for the Lambda function.

Previously, transforming this diagram into infrastructure as code would require me to manually interpret each component and write the corresponding configuration. With image support, I can now automate much of this process and refine the generated code through a conversation with Q Developer. I can then have a conversation with Q Developer to refine the generated code, ask questions about specific implementation details, or request modifications based on additional requirements and output the code to a .tf file.

Use-case 2: Converting ER diagrams to database schemas

For our second scenario, let’s consider a use case where I’m a part of a data modeling team developing a course management software for universities. I have created an entity-relationship (ER) diagram for their core data structures. I can now use Q developer to help me convert the ER diagram to SQL.

Image shows an Entity Relationship Diagram with relationships between entities such as Courses, Students, Instructors, and Departments with their attributes.

Course management Entity Relationship Diagram

In the following screenshot, I asked the Q Developer CLI to use the ER diagram to create the database schema.

Screenshot of Amazon Q Developer CLI interface showing the beginning of a generated design document with system architecture and process flow sections based on the hand-drawn diagram

CLI with user prompt and SQL generated by Q Developer

The image shows a continuation of SQL Code response from Amazon Q Developer CLI for table creation generated from the ER Diagram reference.

CLI with SQL generated by Q Developer

The prior image shows the response the that Q Developer CLI generated.

Q Developer analyzed the diagram, identified entities, attributes, and relationships, then generated the appropriate SQL code for creating the database schema.

After Q Developer produces the results, I can refine this schema through a conversation with Q Developer by requesting changes to string lengths, indexes, etc., or requesting explanations of design decisions.

Use-case 3: Converting a hand drawn image to a design document

Consider a scenario where I have brainstormed an idea on paper and I would like to share this with my team. In the following image, I have hand drawn the order flow for a website. When the website user orders books from the website, the application updates inventory, then calls the payment and delivery actions. I can now use the Q Developer CLI to draft documentation from the hand drawn idea.

Hand-drawn flowchart showing the order process for a book website, including steps for order placement, inventory update, payment processing, and delivery actions

Hand drawn order flow for a website

In the following example, I asked Q Developer to write a design document using this image as a reference.

Amazon Q Developer CLI interface showing a command prompt with image input and the resulting generated code response.

CLI with user prompt and response generated by Q Developer

The above screenshot shows that, Q Developer first read the image and understood the content from the hand drawn diagram image.

The image shows a continuation of Design documentation response from Amazon Q Developer CLI for table creation generated from the ER Diagram reference.

CLI with the response generated by Q Developer

The prior screen shot is a portion of the response that Q Developer CLI has generated.

Q Developer converted the idea into a design document including system architecture, process flow, data model, functional requirements, and technical requirements. I can also ask Q Developer to output the context to a .md file. This reduces the amount of time going from idea to execution and streamlines document writing.

Use-case 4: Building a UI mockup/wireframe from a screen shot

Let’s say, I want to get started with building a User Interface (UI) from my design document from use-case 3. I can provide a reference image to Q Developer for generating initial wireframes for my UI.

Screenshot of a sample book sales website.

Sample book sales website home page

In this example, I asked Q Developer to help generate a front-end for a new website in Vue.js

Amazon Q Developer CLI interface showing a command prompt with image input and the resulting generated code response. The screenshot shows Amazon Q Developer CLI generating Vue.js setup instructions

CLI with the user prompt and response generated by Q Developer

The image shows a continuation of Vue.js code response from Amazon Q Developer CLI that uses the book wesbite screenshot as a reference.

CLI with Vue.js code generated by Q Developer

The prior image shows a portion of the Vue.js code generated by the Q Developer CLI to re-produce the front-end of the website in the screenshot. Once I verify the code, I can then ask Q Developer CLI to create these files locally.

This approach reduces the error-prone aspects of wireframe creation, allowing me to focus on creative design decisions instead of repetitive setup tasks. In this way, I can accelerate development cycles, ensure consistency across components, and provide a foundation that can be easily customized to meet specific project requirements.

Additional possibilities:

Apart from the prior examples, Q Developer CLI can analyze many types of images, including:

  • Flow charts and process diagrams
  • Class diagrams for object-oriented design
  • Network topology diagrams
  • Screenshots of error messages or application states

This versatility makes Q Developer CLI a powerful tool for various development workflows.

Conclusion:

The addition of image support to Amazon Q Developer CLI represents a significant step forward in bridging the gap between visual and textual representations in software development. By allowing me to work with diagrams and other visual assets directly from the command line, Amazon Q Developer improves my efficiency in translating design into implementation, reducing errors and accelerating development cycles. I encourage you to explore this new capability and discover how it can enhance your development workflow.

To learn more about Q Developer and its capabilities, visit the documentation.

About the Author: 

Authors-image

Keerthi Sreenivas Konjety

Keerthi Sreenivas Konjety is a Specialist Solutions Architect for Amazon Q Developer, with over 3.5 years of experience in AI, ML and Data Engineering. Her expertise lies in enabling developer productivity for AWS customers. Outside work, she enjoys photography and AI content creation.

Configure System Integrity Protection (SIP) on Amazon EC2 Mac instances

Post Syndicated from Sébastien Stormacq original https://aws.amazon.com/blogs/aws/configure-system-integrity-protection-sip-on-amazon-ec2-mac-instances/

I’m pleased to announce developers can now programmatically disable Apple System Integrity Protection (SIP) on their Amazon EC2 Mac instances. System Integrity Protection (SIP), also known as rootless, is a security feature introduced by Apple in OS X El Capitan (2015, version 10.11). It’s designed to protect the system from potentially harmful software by restricting the power of the root user account. SIP is enabled by default on macOS.

SIP safeguards the system by preventing modification of protected files and folders, restricting access to system-owned files and directories, and blocking unauthorized software from selecting a startup disk. The primary goal of SIP is to address the security risk linked to unrestricted root access, which could potentially allow malware to gain full control of a device with just one password or vulnerability. By implementing this protection, Apple aims to ensure a higher level of security for macOS users, especially considering that many users operate on administrative accounts with weak or no passwords.

While SIP provides excellent protection against malware for everyday use, developers might occasionally need to temporarily disable it for development and testing purposes. For instance, when creating a new device driver or system extension, disabling SIP is necessary to install and test the code. Additionally, SIP might block access to certain system settings required for your software to function properly. Temporarily disabling SIP grants you the necessary permissions to fine-tune programs for macOS. However, it’s crucial to remember that this is akin to briefly disabling the vault door for authorized maintenance, not leaving it permanently open.

Disabling SIP on a Mac requires physical access to the machine. You have to restart the machine in recovery mode, then disable SIP with the csrtutil command line tool, then restart the machine again.

Until today, you had to operate with the standard SIP settings on EC2 Mac instances. The physical access requirement and the need to boot in recovery mode made integrating SIP with the Amazon EC2 control plane and EC2 API challenging. But that’s no longer the case! You can now disable and re-enable SIP at will on your Amazon EC2 Mac instances. Let me show you how.

Let’s see how it works
Imagine I have an Amazon EC2 Mac instance started. It’s a mac2-m2.metal instance, running on an Apple silicon M2 processor. Disabling or enabling SIP is as straightforward as calling a new EC2 API: CreateMacSystemIntegrityProtectionModificationTask. This API is asynchronous; it starts the process of changing the SIP status on your instance. You can monitor progress using another new EC2 API: DescribeMacModificationTasks. All I need to know is the instance ID of the machine I want to work with.

Prerequisites
On Apple silicon based EC2 Mac instances and more recent type of machines, before calling the new EC2 API, I must set the ec2-user user password and enable secure token for that user on macOS. This requires connecting to the machine and typing two commands in the terminal.

# on the target EC2 Mac instance
# Set a password for the ec2-user user
~ % sudo /usr/bin/dscl . -passwd /Users/ec2-user
New Password: (MyNewPassw0rd)

# Enable secure token, with the same password, for the ec2-user
# old password is the one you just set with dscl
~ % sysadminctl -newPassword MyNewPassw0rd -oldPassword MyNewPassw0rd
2025-03-05 13:16:57.261 sysadminctl[3993:3033024] Attempting to change password for ec2-user…
2025-03-05 13:16:58.690 sysadminctl[3993:3033024] SecKeychainCopyLogin returned -25294
2025-03-05 13:16:58.690 sysadminctl[3993:3033024] Failed to update keychain password (-25294)
2025-03-05 13:16:58.690 sysadminctl[3993:3033024] - Done

# The error about the KeyChain is expected. I never connected with the GUI on this machine, so the Login keychain does not exist
# you can ignore this error.  The command below shows the list of keychains active in this session
~ % security list
    "/Library/Keychains/System.keychain"

# Verify that the secure token is ENABLED
~ % sysadminctl -secureTokenStatus ec2-user
2025-03-05 13:18:12.456 sysadminctl[4017:3033614] Secure token is ENABLED for user ec2-user

Change the SIP status
I don’t need to connect to the machine to toggle the SIP status. I only need to know its instance ID. I open a terminal on my laptop and use the AWS Command Line Interface (AWS CLI) to retrieve the Amazon EC2 Mac instance ID.

 aws ec2 describe-instances \
         --query "Reservations[].Instances[?InstanceType == 'mac2-m2.metal' ].InstanceId" \
         --output text

i-012a5de8da47bdff7

Now, still from the terminal on my laptop, I disable SIP with the create-mac-system-integrity-protection-modification-task command:

echo '{"rootVolumeUsername":"ec2-user","rootVolumePassword":"MyNewPassw0rd"}' > tmpCredentials
aws ec2 create-mac-system-integrity-protection-modification-task \
--instance-id "i-012a5de8da47bdff7" \
--mac-credentials fileb://./tmpCredentials \
--mac-system-integrity-protection-status "disabled" && rm tmpCredentials

{
    "macModificationTask": {
        "instanceId": "i-012a5de8da47bdff7",
        "macModificationTaskId": "macmodification-06a4bb89b394ac6d6",
        "macSystemIntegrityProtectionConfig": {},
        "startTime": "2025-03-14T14:15:06Z",
        "taskState": "pending",
        "taskType": "sip-modification"
    }
}

After the task is started, I can check its status with the aws ec2 describe-mac-modification-tasks command.

{
    "macModificationTasks": [
        {
            "instanceId": "i-012a5de8da47bdff7",
            "macModificationTaskId": "macmodification-06a4bb89b394ac6d6",
            "macSystemIntegrityProtectionConfig": {
                "debuggingRestrictions": "",
                "dTraceRestrictions": "",
                "filesystemProtections": "",
                "kextSigning": "",
                "nvramProtections": "",
                "status": "disabled"
            },
            "startTime": "2025-03-14T14:15:06Z",
            "tags": [],
            "taskState": "in-progress",
            "taskType": "sip-modification"
        },
...

The instance initiates the process and a series of reboots, during which it becomes unreachable. This process can take 60–90 minutes to complete. After that, when I see the status in the console becoming available again, I connect to the machine through SSH or EC2 Instance Connect, as usual.

➜  ~ ssh [email protected]
Warning: Permanently added '54.99.9.99' (ED25519) to the list of known hosts.
Last login: Mon Feb 26 08:52:42 2024 from 1.1.1.1

    ┌───┬──┐   __|  __|_  )
    │ ╷╭╯╷ │   _|  (     /
    │  └╮  │  ___|\___|___|
    │ ╰─┼╯ │  Amazon EC2
    └───┴──┘  macOS Sonoma 14.3.1

➜  ~ uname -a
Darwin Mac-mini.local 23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:30:27 PST 2023; root:xnu-10002.81.5~7/RELEASE_ARM64_T8103 arm64

➜ ~ csrutil --status 
System Integrity Protection status: disabled.

When to disable SIP
Disabling SIP should be approached with caution because it opens up the system to potential security risks. However, as I mentioned in the introduction of this post, you might need to disable SIP when developing device drivers or kernel extensions for macOS. Some older applications might also not function correctly when SIP is enabled.

Disabling SIP is also required to turn off Spotlight indexing. Spotlight can help you quickly find apps, documents, emails and other items on your Mac. It’s very convenient on desktop machines, but not so much on a server. When there is no need to index your documents as they change, turning off Spotlight will release some CPU cycles and disk I/O.

Things to know
There are a couple of additional things to know about disabling SIP on Amazon EC2 Mac:

  • Disabling SIP is available through the API and AWS SDKs, the AWS CLI, and the AWS Management Console.
  • On Apple silicon, the setting is volume based. So if you replace the root volume, you need to disable SIP again. On Intel, the setting is Mac host based, so if you replace the root volume, SIP will still be disabled.
  • After disabling SIP, it will be enabled again if you stop and start the instance. Rebooting an instance doesn’t change its SIP status.
  • SIP status isn’t transferable between EBS volumes. This means SIP will be disabled again after you restore an instance from an EBS snapshot or if you create an AMI from an instance where SIP is enabled.

These new APIs are available in all Regions where Amazon EC2 Mac is available, at no additional cost. Try them today.

— seb


How is the News Blog doing? Take this 1 minute survey!

(This survey is hosted by an external company. AWS handles your information as described in the AWS Privacy Notice. AWS will own the data gathered via this survey and will not share the information collected with survey respondents.)

FM-Intent: Predicting User Session Intent with Hierarchical Multi-Task Learning

Post Syndicated from Netflix Technology Blog original https://netflixtechblog.com/fm-intent-predicting-user-session-intent-with-hierarchical-multi-task-learning-94c75e18f4b8

Authors: Sejoon Oh, Moumita Bhattacharya, Yesu Feng, Sudarshan Lamkhede, Ko-Jen Hsiao, and Justin Basilico

Motivation

Recommender systems have become essential components of digital services across e-commerce, streaming media, and social networks [1, 2]. At Netflix, these systems drive significant product and business impact by connecting members with relevant content at the right time [3, 4]. While our recommendation foundation model (FM) has made substantial progress in understanding user preferences through large-scale learning from interaction histories (please refer to this article about FM @ Netflix), there is an opportunity to further enhance its capabilities. By extending FM to incorporate the prediction of underlying user intents, we aim to enrich its understanding of user sessions beyond next-item prediction, thereby offering a more comprehensive and nuanced recommendation experience.

Recent research has highlighted the importance of understanding user intent in online platforms [5, 6, 7, 8]. As Xia et al. [8] demonstrated at Pinterest, predicting a user’s future intent can lead to more accurate and personalized recommendations. However, existing intent prediction approaches typically employ simple multi-task learning that adds intent prediction heads to next-item prediction models without establishing a hierarchical relationship between these tasks.

To address these limitations, we introduce FM-Intent, a novel recommendation model that enhances our foundation model through hierarchical multi-task learning. FM-Intent captures a user’s latent session intent using both short-term and long-term implicit signals as proxies, then leverages this intent prediction to improve next-item recommendations. Unlike conventional approaches, FM-Intent establishes a clear hierarchy where intent predictions directly inform item recommendations, creating a more coherent and effective recommendation pipeline.

FM-Intent makes three key contributions:

  1. A novel recommendation model that captures user intent on the Netflix platform and enhances next-item prediction using this intent information.
  2. A hierarchical multi-task learning approach that effectively models both short-term and long-term user interests.
  3. Comprehensive experimental validation showing significant performance improvements over state-of-the-art models, including our foundation model.

Understanding User Intent in Netflix

In the Netflix ecosystem, user intent manifests through various interaction metadata, as illustrated in Figure 1. FM-Intent leverages these implicit signals to predict both user intent and next-item recommendations.

Figure 1: Overview of user engagement data in Netflix. User intent can be associated with several interaction metadata. We leverage various implicit signals to predict user intent and next-item.

In Netflix, there can be multiple types of user intents. For instance,

Action Type: Categories reflecting what users intend to do on Netflix, such as discovering new content versus continuing previously started content. For example, when a member plays a follow-up episode of something they were already watching, this can be categorized as “continue watching” intent.

Genre Preference: The pre-defined genre labels (e.g., Action, Thriller, Comedy) that indicate a user’s content preferences during a session. These preferences can shift significantly between sessions, even for the same user.

Movie/Show Type: Whether a user is looking for a movie (typically a single, longer viewing experience) or a TV show (potentially multiple episodes of shorter duration).

Time-since-release: Whether the user prefers newly released content, recent content (e.g., between a week and a month), or evergreen catalog titles.

These dimensions serve as proxies for the latent user intent, which is often not directly observable but crucial for providing relevant recommendations.

FM-Intent Model Architecture

FM-Intent employs a hierarchical multi-task learning approach with three major components, as illustrated in Figure 2.

Figure 2: An architectural illustration of our hierarchical multi-task learning model FM-Intent for user intent and item predictions. We use ground-truth intent and item-ID labels to optimize predictions.

1. Input Feature Sequence Formation

The first component constructs rich input features by combining interaction metadata. The input feature for each interaction combines categorical embeddings and numerical features, creating a comprehensive representation of user behavior.

2. User Intent Prediction

The intent prediction component processes the input feature sequence through a Transformer encoder and generates predictions for multiple intent signals.

The Transformer encoder effectively models the long-term interest of users through multi-head attention mechanisms. For each prediction task, the intent encoding is transformed into prediction scores via fully-connected layers.

A key innovation in FM-Intent is the attention-based aggregation of individual intent predictions. This approach generates a comprehensive intent embedding that captures the relative importance of different intent signals for each user, providing valuable insights for personalization and explanation.

3. Next-Item Prediction with Hierarchical Multi-Task Learning

The final component combines the input features with the user intent embedding to make more accurate next-item recommendations.

FM-Intent employs hierarchical multi-task learning where intent predictions are conducted first, and their results are used as input features for the next-item prediction task. This hierarchical relationship ensures that the next-item recommendations are informed by the predicted user intent, creating a more coherent and effective recommendation model.

Offline Results

We conducted comprehensive offline experiments on sampled Netflix user engagement data to evaluate FM-Intent’s performance. Note that FM-Intent uses a much smaller dataset for training compared to the FM production model due to its complex hierarchical prediction architecture.

Next-Item and Next-Intent Prediction Accuracy

Table 1 compares FM-Intent with several state-of-the-art sequential recommendation models, including our production model (FM-Intent-V0).

Table 1: Next-item and next-intent prediction results of baselines and our proposed method FM-Intent on the Netflix user engagement dataset.

All metrics are represented as relative % improvements compared to the SOTA baseline: TransAct. N/A indicates that a model is not capable of predicting a certain intent. Note that we added additional fully-connected layers to LSTM, GRU, and Transformer baselines in order to predict user intent, while we used original implementations for other baselines. FM-Intent demonstrates statistically significant improvement of 7.4% in next-item prediction accuracy compared to the best baseline (TransAct).

Most baseline models show limited performance as they either cannot predict user intent or cannot incorporate intent predictions into next-item recommendations. Our production model (FM-Intent-V0) performs well but lacks the ability to predict and leverage user intent. Note that FM-Intent-V0 is trained with a smaller dataset for a fair comparison with other models; the actual production model is trained with a much larger dataset.

Qualitative Analysis: User Clustering

Figure 3: K-means++ (K=10) clustering of user intent embeddings found by FM-Intent; FM-Intent finds unique clusters of users that share the similar intent.

FM-Intent generates meaningful user intent embeddings that can be used for clustering users with similar intents. Figure 3 visualizes 10 distinct clusters identified through K-means++ clustering. These clusters reveal meaningful user segments with distinct viewing patterns:

  • Users who primarily discover new content versus those who continue watching recent/favorite content.
  • Genre enthusiasts (e.g., anime/kids content viewers).
  • Users with specific viewing patterns (e.g., Rewatchers versus casual viewers).

Potential Applications of FM-Intent

FM-Intent has been successfully integrated into Netflix’s recommendation ecosystem, can be leveraged for several downstream applications:

Personalized UI Optimization: The predicted user intent could inform the layout and content selection on the Netflix homepage, emphasizing different rows based on whether users are in discovery mode, continue-watching mode, or exploring specific genres.

Analytics and User Understanding: Intent embeddings and clusters provide valuable insights into viewing patterns and preferences, informing content acquisition and production decisions.

Enhanced Recommendation Signals: Intent predictions serve as features for other recommendation models, improving their accuracy and relevance.

Search Optimization: Real-time intent predictions help prioritize search results based on the user’s current session intent.

Conclusion

FM-Intent represents an advancement in Netflix’s recommendation capabilities by enhancing them with hierarchical multi-task learning for user intent prediction. Our comprehensive experiments demonstrate that FM-Intent significantly outperforms state-of-the-art models, including our prior foundation model that focused solely on next-item prediction. By understanding not just what users might watch next but what underlying intents users have, we can provide more personalized, relevant, and satisfying recommendations.

Acknowledgements

We thank our stunning colleagues in the Foundation Model team & AIMS org. for their valuable feedback and discussions. We also thank our partner teams for getting this up and running in production.

References

[1] Amatriain, X., & Basilico, J. (2015). Recommender systems in industry: A netflix case study. In Recommender systems handbook (pp. 385–419). Springer.

[2] Gomez-Uribe, C. A., & Hunt, N. (2015). The netflix recommender system: Algorithms, business value, and innovation. ACM Transactions on Management Information Systems (TMIS), 6(4), 1–19.

[3] Jannach, D., & Jugovac, M. (2019). Measuring the business value of recommender systems. ACM Transactions on Management Information Systems (TMIS), 10(4), 1–23.

[4] Bhattacharya, M., & Lamkhede, S. (2022). Augmenting Netflix Search with In-Session Adapted Recommendations. In Proceedings of the 16th ACM Conference on Recommender Systems (pp. 542–545).

[5] Chen, Y., Liu, Z., Li, J., McAuley, J., & Xiong, C. (2022). Intent contrastive learning for sequential recommendation. In Proceedings of the ACM Web Conference 2022 (pp. 2172–2182).

[6] Ding, Y., Ma, Y., Wong, W. K., & Chua, T. S. (2021). Modeling instant user intent and content-level transition for sequential fashion recommendation. IEEE Transactions on Multimedia, 24, 2687–2700.

[7] Liu, Z., Chen, H., Sun, F., Xie, X., Gao, J., Ding, B., & Shen, Y. (2021). Intent preference decoupling for user representation on online recommender system. In Proceedings of the Twenty-Ninth International Conference on International Joint Conferences on Artificial Intelligence (pp. 2575–2582).

[8] Xia, X., Eksombatchai, P., Pancha, N., Badani, D. D., Wang, P. W., Gu, N., Joshi, S. V., Farahpour, N., Zhang, Z., & Zhai, A. (2023). TransAct: Transformer-based Realtime User Action Model for Recommendation at Pinterest. In Proceedings of the 29th ACM SIGKDD Conference on Knowledge Discovery and Data Mining (pp. 5249–5259).


FM-Intent: Predicting User Session Intent with Hierarchical Multi-Task Learning was originally published in Netflix TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Status report on optional Rust in FreeBSD support

Post Syndicated from jzb original https://lwn.net/Articles/1022040/

Shawn Webb has published a status
report
on work to provide basic support in FreeBSD for userland components
written in Rust.

We introduced a new BSD makefile, located at share/mk/bsd.rust.mk,
that enables building a Rust application during buildworld. As of this
writing, we only support building and installing Rust
applications. Supporting library crates is planned (we would like to
be able to build/install library crates that expose an FFI, like for
C/C++ compatibility). Normal library crates build and install just
fine. Support for cdylib Rust library crates specifically is what’s
missing, but is desired and planned.

We do NOT currently support Rust in the kernel. Kernel support
requires more work that we deemed out-of-scope for this initial
proof-of-concept/work-in-progress patchset. We also do NOT support
building multiple programs in the same BSD Makefile (like with
bsd.progs.mk), though that is also a desired feature.

LWN covered a
discussion about including Rust in the FreeBSD base system in August
2024.

[$] Recent disruptive changes from Setuptools

Post Syndicated from jake original https://lwn.net/Articles/1020576/

In late March, version 78.0.1 of Setuptools — an important
Python packaging tool — was released. It was scarcely half an hour before
the first bug
report
came in, and it quickly became clear that the change was far
more disruptive than anticipated. Within only about five hours 78.0.2 was
published to roll back the change
, and multiple discussions were
started about how to limit the damage caused by future breaking
changes. Nevertheless, many users still felt the response was
inadequate. Some previous Setuptools releases have also caused problems on a smaller but still notable scale, and hopefully the developers will be more cautious going forward. But there are also lessons here for the developers of Python package installers, ordinary Python developers and end users, and even Linux distribution maintainers.

Key Takeaways from the Take Command Summit 2025: Inside the Mind of an Attacker

Post Syndicated from Rapid7 original https://blog.rapid7.com/2025/05/21/key-takeaways-from-the-take-command-summit-2025-inside-the-mind-of-an-attacker/

Key Takeaways from the Take Command Summit 2025: Inside the Mind of an Attacker

In one of the most anticipated sessions of Take Command 2025, Raj Samani, Chief Scientist at Rapid7, sat down with Trent Teyema, former FBI Special Agent and President of CSG Strategies, for a candid conversation on how threat actors are evolving and what defenders must do to keep up.

Moderated by Brian Honan, CEO of BH Consulting, the panel pulled no punches. From the economics of ransomware to the risks of overrelying on static indicators of compromise, Inside the Mind of an Attacker: Navigating the Threat Horizon served as both a wake-up call and a roadmap for modern security strategy.

Cybercrime is thriving — and getting smarter

It’s no longer about lone hackers. As Raj put it, “Ransomware has become a business.” Today’s threat actors are highly organized, well-resourced, and increasingly leveraging professional tools and affiliate networks.

One striking takeaway: groups like RansomHub are reportedly earning tens of millions of dollars per quarter, reinvesting that revenue into toolkits, infrastructure, and even “customer service” operations for negotiating with victims.

Panelists discussed the trend toward secondary extortion tactics, where attackers threaten to notify regulators like the SEC if ransom demands aren’t met — a calculated move to increase pressure without deploying additional payloads.

From indicators to context: why threat intelligence must evolve

One of the biggest challenges facing defenders today is the lack of actionable, context-rich intelligence. While threat intel feeds are abundant, the signal-to-noise ratio is still too high.

“We don’t just need more data. We need better context,” Raj emphasized.

The panel discussed how defenders must move beyond static IOCs and invest in behavioral analysis, context-aware detection, and real-time telemetry to truly stay ahead of threats.

A recent stat from the post-event survey reflects this shift: only 18% of respondents said their organizations integrate threat intelligence into exposure management very effectively.

To beat an attacker, think like one

The message came through clearly: organizations that adopt a proactive, attacker-informed mindset are better equipped to defend against modern threats. That means:

  • Red teaming with real-world attacker playbooks
  • Understanding how ransomware operators stage and execute campaigns
  • Practicing lateral movement detection before it happens

Trent Teyema, drawing on his FBI experience, pointed out that too many organizations still rely on legacy thinking: “They treat cyber like IT, when they should be treating it like crime.”

Paying ransoms: a business risk, not a moral judgment

Both speakers addressed the uncomfortable reality: sometimes ransoms are paid. And while this remains a contentious topic, the panel framed it clearly – it’s a business decision, not a moral one.

Raj urged teams to have ransomware playbooks and decision frameworks defined in advance. This includes:

  • Knowing legal constraints (especially around sanctions and OFAC-listed entities)
  • Understanding the implications of payment
  • Engaging with experienced negotiation partners if needed

Visibility still reigns supreme

From attack surface awareness to SOC visibility gaps, the theme of visibility was woven throughout the session.

As Raj noted, “You can’t protect what you don’t know about.”

The panel closed with a call to action: unify your data, reduce siloed tools, and build detection and response around context, not just coverage.

Watch the full session on demand

If you missed this conversation — or want to rewatch it with your team — the full session is now available.

[Watch Inside the Mind of an Attacker On Demand]

Security updates for Wednesday

Post Syndicated from jzb original https://lwn.net/Articles/1022030/

Security updates have been issued by AlmaLinux (.NET 8.0, avahi, buildah, compat-openssl10, compat-openssl11, expat, firefox, gimp, git, grafana, libsoup, libxslt, mod_auth_openidc, nginx, nodejs:22, osbuild-composer, php, redis, redis:7, skopeo, thunderbird, vim, webkit2gtk3, xterm, and yelp), Arch Linux (dropbear, freetype2, go, nodejs, nodejs-lts-iron, nodejs-lts-jod, python-django, webkit2gtk, webkit2gtk-4.1, webkitgtk-6.0, and wpewebkit), Debian (mongo-c-driver), Fedora (openssh, perl-Mojolicious, thunderbird, yelp, and yelp-xsl), Red Hat (firefox, java-1.8.0-openjdk, java-11-openjdk with Extended Lifecycle Support, java-21-ibm-semeru-certified-jdk, java-21-openjdk, kernel, libxslt, ruby, ruby:3.1, ruby:3.3, unbound, and webkit2gtk3), SUSE (glib2, grub2, kernel, libwebp, openssh, and s390-tools), and Ubuntu (linux, linux-azure, linux-azure-6.11, linux-gcp, linux-gcp-6.11, linux-hwe-6.11, linux-oem-6.11, linux-raspi, linux-realtime, linux-azure, linux-azure-5.15, linux-nvidia-tegra, linux-azure, linux-azure-6.8, linux-oem-6.8, linux-azure, linux-kvm, linux-azure-fips, linux-azure-nvidia, linux-gcp, linux-gcp-6.8, linux-gkeop, linux-gke, linux-intel-iot-realtime, linux-realtime, linux-raspi-realtime, mariadb-10.6, and postgresql-12, postgresql-14, postgresql-16).

Bringing connections into view: real-time BGP route visibility on Cloudflare Radar

Post Syndicated from Mingwei Zhang original https://blog.cloudflare.com/bringing-connections-into-view-real-time-bgp-route-visibility-on-cloudflare/

The Internet relies on the Border Gateway Protocol (BGP) to exchange IP address reachability information. This information outlines the path a sender or router can use to reach a specific destination. These paths, conveyed in BGP messages, are sequences of Autonomous System Numbers (ASNs), with each ASN representing an organization that operates its own segment of Internet infrastructure.

Throughout this blog post, we’ll use the terms “BGP routes” or simply “routes” to refer to these paths. In essence, BGP functions by enabling autonomous systems to exchange routes to IP address blocks (“IP prefixes”), allowing different entities across the Internet to construct their routing tables.

When network operators debug reachability issues or assess a resource’s global reach, BGP routes are often the first thing they examine. Therefore, it’s critical to have an up-to-date view of the routes toward the IP prefixes of interest. Some networks provide tools called “looking glasses” — public routing information services offering data directly from their own BGP routers. These allow external operators to examine routes from that specific network’s perspective. Furthermore, services like bgp.tools, bgp.he.net, RouteViews, or the NLNOG RING looking glass offer aggregated, looking glass-like lookup capabilities, drawing on data sources from multiple organizations rather than just a single one.

However, individual looking glass instances offer a limited scope, typically restricted to the infrastructure of the service provider’s network. While aggregated routing information services provide broader vantage points, they often lack the API access necessary for building automated tools on top of them. For example, systems designed for automated tasks, such as BGP leak or hijack detection, depend on programmatic API access.

We’re excited to introduce Cloudflare Radar’s new real-time BGP route lookup service, described below. Built using public data sources, this service provides visualizations of real-time routes directly on the corresponding IP prefix pages within Radar (see the page for 1.1.1.0/24 as an example). We are also offering API access through our free-to-use Cloudflare Radar API, empowering developers to leverage this data to build their own innovative systems and tools.

Cloudflare Radar provides real-time routes

We are excited to announce the launch of our new real-time BGP route lookup service, now accessible through both Cloudflare Radar web interface and the Cloudflare Radar API. This enhancement provides users with a near instantaneous view into global BGP routing data.

Cloudflare Radar prefix pages

Cloudflare Radar’s real-time routes feature now offers a Sankey diagram illustrating the BGP routes for a given prefix. To minimize visual complexity, the visualization displays routes directed towards the Tier 1 networks. For example, the diagram below shows that 1.1.1.0/24 is announced by AS13335 (Cloudflare) and that Cloudflare has direct connections to almost all U.S.-based and international Tier 1 network providers.


Expanding on this more concise view, users also have the option to ‘Show full paths’ and visualize every BGP route from the prefix of interest to the collectors. (The role of the collectors in gathering this data is discussed below.) The interactive view allows panning and zooming, and hovering over the links provides tooltip information on which collector saw the route and when it was last updated.


For both views, the prefix origin table is displayed above the route’s visualization. The table shows the originating Autonomous System (AS), the visibility percentage (representing the proportion of route collectors observing the origin ASN announcement), and RPKI validation outcomes.

During a recently detected BGP misconfiguration, we saw two origin ASNs for a prefix, with AS3 incorrectly used instead of the intended origin being prepended three times. The visualization reveals AS3 as RPKI invalid with low visibility, indicating limited network acceptance. Operators can analyze these issues visually or in the table and monitor real-time corrections by refreshing the page.


Whether facing network outages, implementing new deployments, or investigating route leaks, users can leverage this feature for any scenario where a clear, global understanding of a prefix’s routing paths is essential.

To allow easier access to this information, users can now search for any prefix using the Radar search bar and navigate to the corresponding prefix routing pages. Prefixes involved in BGP route leak and origin hijack events are also linked to this enhanced routing information page, helping operators debug BGP anomalies in real-time.


Cloudflare Routes API

Cloudflare Radar real-time route data is also accessible via the Radar API, and users can follow this guide to get started.


The following example shows an HTTP GET request to query all the current routes for a prefix of interest:

curl -X GET 
"https://api.cloudflare.com/client/v4/radar/bgp/routes/realtime?prefix=1.1.1.0/24" -H 
"Authorization: Bearer <API_TOKEN>"

With the help of JSON data processing tools like jq, users can further filter data results by routes containing a certain ASN. In the following example, we make a request to ask for all current routes toward the prefix 1.1.1.0/24 and filter all routes with AS paths containing AS174:

curl -X GET
 "https://api.cloudflare.com/client/v4/radar/bgp/routes/realtime?prefix=1.1.1.0/24" \
    -H "Authorization: Bearer <API_TOKEN>" | \
jq '.result.routes[]|select(.as_path | contains([174]))'

The command output is a JSON array of route objects. Each object details a route that includes AS174 in its AS path. Additional information provided for each route includes the BGP route collector, BGP community values, and the timestamp of the last update.

{
  "as_path": [
    3130,
    174,
    13335
  ],
  "collector": "route-views2",
  "communities": [
    "174:21001",
    "174:22013",
    "3130:394"
  ],
  "peer_asn": 3130,
  "prefix": "1.1.1.0/24",
  "timestamp": "2025-05-14T00:00:00Z"
}
{
  "as_path": [
    263237,
    174,
    13335
  ],
  "collector": "rrc15",
  "communities": [
    "174:21001",
    "174:22013",
    "65237:174"
  ],
  "peer_asn": 263237,
  "prefix": "1.1.1.0/24",
  "timestamp": "2025-05-14T01:39:52Z"
}

The API also offers supplementary metadata alongside BGP route information, including insights into BGP route collector status and aggregated prefix-to-origin data. Recalling the earlier example of an AS path prepending misconfiguration, the RPKI invalid AS3 origin is now directly visible to users and API clients in the JSON response, showing that just 9% of all collectors observed its announcements.

"meta": {
  "collectors": [
    {
      "latest_realtime_ts": "2025-05-19T21:35:40Z",
      "latest_rib_ts": "2025-05-19T20:00:00Z",
      "latest_updates_ts": "2025-05-19T21:15:00Z",
      "peers_count": 24,
      "peers_v4_count": 0,
      "peers_v6_count": 24,
      "collector": "route-views6"
    },
  ],
  "prefix_origins": [
    {
      "origin": 3,
      "prefix": "2804:4e28::/32",
      "rpki_validation": "invalid",
      "total_peers": 121,
      "total_visible": 11,
      "visibility": 0.09090909090909091
    },
    {
      "origin": 268243,
      "prefix": "2804:4e28::/32",
      "rpki_validation": "valid",
      "total_peers": 121,
      "total_visible": 94,
      "visibility": 0.7768595041322314
    }
  ],
}

From archives to real-time

Architecture overview

Cloudflare Radar uses RIPE RIS and the University of Oregon’s RouteViews as our primary BGP data sources for services like the routing statistics widget, anomaly detection, and announced address space graphs. We have previously discussed in detail on how we use the data archives from these two providers to build Cloudflare Radar’s routing pages, and our route leak and hijack detection systems.

In brief, RIPE RIS and RouteViews maintain several BGP route collectors, each connected to BGP routers across a diverse set of networks. These routers forward BGP messages to the collectors, which generate periodic data dumps for public access. These data dumps include both collections of BGP message updates and full routing table snapshots (RIB dump files).

For services monitoring stable routing information, like global routing statistics, we process RIB dump files from the archives as they become available. Conversely, for detecting dynamic events such as route leaks and hijacks, we process periodic BGP update files in batches. Services depending on this historical BGP data may experience processing delays of 10 to 30 minutes at the route collectors.


For the new real-time BGP routes feature, we aim to reduce the data delay from minutes or tens of minutes down to seconds. With the real-time stream capability provided by the BGP archiver services — RIS Live WebSocket from RIPE RIS and OpenBMP Kafka stream from RouteViews — we designed an additional real-time data stream component that enhances the routes snapshots built with MRT archive files by constantly updating the snapshots.


System design

At its core, the system enables a user to look up a prefix’s routes stored in BGP routes snapshots. The BGP routes snapshots serve as a queryable data repository, organized hierarchically. The snapshots use a trie structure to allow for the retrieval of route information (such as AS paths and community values) associated with specific address prefixes. Each node in the hierarchy stores routing information from different peering routers, providing a consolidated global view. To handle the large data volumes from multiple BGP route collectors, the system partitions routing data into separate BGP routes snapshots, where each snapshot receives data streamed from its corresponding collector. This architecture enables horizontal scalability, allowing for dynamic adjustment of data sources by selecting which independent collectors’ data to include or exclude.


Because the collectors’ BGP route information is maintained independently, to query for a global status, we apply the actor model software architecture for the implementation. Each collector is considered an actor that runs completely independently and communicates with a central controller via a dedicated communication channel. The central controller starts all actors by sending a signal to each of them, triggering actors to start collecting archival and real-time BGP data, on their separate threads.

Upon queries from users, the central controller will relay the query to all running actors via a query message. The actors will retrieve the corresponding route information on its prefix-trie and return the results to the controller with another message. The controller aggregates all messages from the actors and compiles them into a reply response to the user. During the whole process, the real-time BGP streaming and snapshots’ updating processes continue to run in the background without interruptions.


Our actor-model implementation enables a single node to efficiently store hundreds of full routing tables in its memory. Our current deployment uses eight route collectors, housing a total of 261 full routing tables. This in-memory system operating on a single node consumes approximately 45 GB of memory, which translates to about 170 MB per full routing table.

Summary

Cloudflare Radar now offers a real-time BGP route lookup service, providing near-instantaneous insights into global Internet routing. This feature leverages real-time data streams from RouteViews and RIPE RIS, moving beyond historical archives to deliver up-to-the-minute information. Users can now visualize routes in real time on Cloudflare Radar’s prefix pages with intuitive Sankey diagrams that detail complete route information. Furthermore, the Cloudflare Radar API provides programmatic access to this data, allowing for seamless integration into custom tools and workflows.

Visit Cloudflare Radar for additional insights around Internet disruptions, routing issues, Internet traffic trends, attacks, and Internet quality. Follow us on social media at @CloudflareRadar (X), noc.social/@cloudflareradar (Mastodon), and radar.cloudflare.com (Bluesky), or contact us via email.

More AIs Are Taking Polls and Surveys

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/05/more-ais-are-taking-polls-and-surveys.html

I already knew about the declining response rate for polls and surveys. The percentage of AI bots that respond to surveys is also increasing.

Solutions are hard:

1. Make surveys less boring.
We need to move past bland, grid-filled surveys and start designing experiences people actually want to complete. That means mobile-first layouts, shorter runtimes, and maybe even a dash of storytelling. TikTok or dating app style surveys wouldn’t be a bad idea or is that just me being too much Gen Z?

2. Bot detection.
There’s a growing toolkit of ways to spot AI-generated responses—using things like response entropy, writing style patterns or even metadata like keystroke timing. Platforms should start integrating these detection tools more widely. Ideally, you introduce an element that only humans can do, e.g., you have to pick up your price somewhere in-person. Btw, note that these bots can easily be designed to find ways around the most common detection tactics such as Captcha’s, timed responses and postcode and IP recognition. Believe me, way less code than you suspect is needed to do this.

3. Pay people more.
If you’re only offering 50 cents for 10 minutes of mental effort, don’t be surprised when your respondent pool consists of AI agents and sleep-deprived gig workers. Smarter, dynamic incentives—especially for underrepresented groups—can make a big difference. Perhaps pay-differentiation (based on simple demand/supply) makes sense?

4. Rethink the whole model.
Surveys aren’t the only way to understand people. We can also learn from digital traces, behavioral data, or administrative records. Think of it as moving from a single snapshot to a fuller, blended picture. Yes, it’s messier—but it’s also more real.

The collective thoughts of the interwebz