Post Syndicated from xkcd.com original https://xkcd.com/3219/

Post Syndicated from xkcd.com original https://xkcd.com/3219/

Post Syndicated from The Atlantic original https://www.youtube.com/shorts/9PkFq97u8Vw
Post Syndicated from Channy Yun (윤석찬) original https://aws.amazon.com/blogs/aws/introducing-account-regional-namespaces-for-amazon-s3-general-purpose-buckets/
Today, we’re announcing a new feature of Amazon Simple Storage Service (Amazon S3) you can use to create general purpose buckets in your own account regional namespace simplifying bucket creation and management as your data storage needs grow in size and scope. You can create general purpose bucket names across multiple AWS Regions with assurance that your desired bucket names will always be available for you to use.
With this feature, you can predictably name and create general purpose buckets in your own account regional namespace by appending your account’s unique suffix in your requested bucket name. For example, I can create the bucket mybucket-123456789012-us-east-1-an in my account regional namespace. mybucket is the bucket name prefix that I specified, then I add my account regional suffix to the requested bucket name: -123456789012-us-east-1-an. If another account tries to create buckets using my account’s suffix, their requests will be automatically rejected.
Your security teams can use AWS Identity and Access Management (AWS IAM) policies and AWS Organizations service control policies to enforce that your employees only create buckets in their account regional namespace using the new s3:x-amz-bucket-namespace condition key, helping teams adopt the account regional namespace across your organization.
Create your S3 bucket with account regional namespace in action
To get started, choose Create bucket in the Amazon S3 console. To create your bucket in your account regional namespace, choose Account regional namespace. If you choose this option, you can create your bucket with any name that is unique to your account and region.
This configuration supports all of the same features as general purpose buckets in the global namespace. The only difference is that only your account can use bucket names with your account’s suffix. The bucket name prefix and the account regional suffix combined must be between 3 and 63 characters long.

Using the AWS Command Line Interface (AWS CLI), you can create a bucket with account regional namespace by specifying the x-amz-bucket-namespace:account-regional request header and providing a compatible bucket name.
$ aws s3api create-bucket --bucket mybucket-123456789012-us-east-1-an \
--bucket-namespace account-regional \
--region us-east-1
You can use the AWS SDK for Python (Boto3) to create a bucket with account regional namespace using CreateBucket API request.
import boto3
class AccountRegionalBucketCreator:
"""Creates S3 buckets using account-regional namespace feature."""
ACCOUNT_REGIONAL_SUFFIX = "-an"
def __init__(self, s3_client, sts_client):
self.s3_client = s3_client
self.sts_client = sts_client
def create_account_regional_bucket(self, prefix):
"""
Creates an account-regional S3 bucket with the specified prefix.
Resolves caller AWS account ID using the STS GetCallerIdentity API.
Format: ---an
"""
account_id = self.sts_client.get_caller_identity()['Account']
region = self.s3_client.meta.region_name
bucket_name = self._generate_account_regional_bucket_name(
prefix, account_id, region
)
params = {
"Bucket": bucket_name,
"BucketNamespace": "account-regional"
}
if region != "us-east-1":
params["CreateBucketConfiguration"] = {
"LocationConstraint": region
}
return self.s3_client.create_bucket(**params)
def _generate_account_regional_bucket_name(self, prefix, account_id, region):
return f"{prefix}-{account_id}-{region}{self.ACCOUNT_REGIONAL_SUFFIX}"
if __name__ == '__main__':
s3_client = boto3.client('s3')
sts_client = boto3.client('sts')
creator = AccountRegionalBucketCreator(s3_client, sts_client)
response = creator.create_account_regional_bucket('test-python-sdk')
print(f"Bucket created: {response}")
You can update your infrastructure as code (IaC) tools, such as AWS CloudFormation, to simplify creating buckets in your account regional namespace. AWS CloudFormation offers the pseudo parameters, AWS::AccountId and AWS::Region, making it easy to build CloudFormation templates that create account regional namespace buckets.
The following example demonstrates how you can update your existing CloudFormation templates to start creating buckets in your account regional namespace:
BucketName: !Sub "amzn-s3-demo-bucket-${AWS::AccountId}-${AWS::Region}-an"
BucketNamespace: "account-regional"
Alternatively, you can also use the BucketNamePrefix property to update your CloudFormation template. By using the BucketNamePrefix, you can provide only the customer defined portion of the bucket name and then it automatically adds the account regional namespace suffix based on the requesting AWS account and Region specified.
BucketNamePrefix: 'amzn-s3-demo-bucket'
BucketNamespace: "account-regional"
Using these options, you can build a custom CloudFormation template to easily create general purpose buckets in your account regional namespace.
Things to know
You can’t rename your existing global buckets to bucket names with account regional namespace, but you can create new general purpose buckets in your account regional namespace. Also, the account regional namespace is only supported for general purpose buckets. S3 table buckets and vector buckets already exist in an account-level namespace and S3 directory buckets exist in a zonal namespace.
To learn more, visit Namespaces for general purpose buckets in the Amazon S3 User Guide.
Now available
Creating general purpose buckets in your account regional namespace in Amazon S3 is now available in 37 AWS Regions including the AWS China and AWS GovCloud (US) Regions. You can create general purpose buckets in your account regional namespace at no additional cost.
Give it a try in the Amazon S3 console today and send feedback to AWS re:Post for Amazon S3 or through your usual AWS Support contacts.
— Channy
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/03/iphones-and-ipads-approved-for-nato-classified-data.html
Apple announcement:
…iPhone and iPad are the first and only consumer devices in compliance with the information assurance requirements of NATO nations. This enables iPhone and iPad to be used with classified information up to the NATO restricted level without requiring special software or settings—a level of government certification no other consumer mobile device has met.
This is out of the box, no modifications required.
Boing Boing post.
Post Syndicated from George'son Tib original https://aws.amazon.com/blogs/security/how-to-manage-the-lifecycle-of-amazon-machine-images-using-ami-lineage-for-aws/
As organizations scale their cloud infrastructure, maintaining proper lifecycle management of Amazon Machine Images (AMIs) is a critical component of their security and risk management goals. AMIs provide the essential information required to launch Amazon Elastic Compute Cloud (Amazon EC2) instances, however; they present security and compliance challenges if not tracked and managed throughout their lifecycle. This blog post explores how organizations can meet their evolving security and compliance requirements by managing potential vulnerabilities across the AMIs deployed throughout their AWS environment.
At the end of 2024, AWS announced lineage supportfor Amazon EC2, providing source details for your AMIs. With this lineage information, you can trace copied or derived AMIs back to their original source. The source AMI information is available for AMIs that were created using specific API commands like CreateImage, CopyImage, and CreateRestoreImageTask. If the AMI was created using a different API command, the ID and AWS Region of the source AMI don’t appear, which can create visibility gaps that potentially impact security and compliance efforts.
To address these gaps and provide comprehensive AMI governance, organizations need to build additional capabilities to analyze the scope of impact of Common Vulnerabilities and Exposures (CVEs), ensure deployed resources originate from an approved golden image, and respond to audit inquiries that require a clear chain of custody for AMIs. A well-designed solution should also help track and enforce approved AMI creation patterns across all accounts and AWS Regions. The AMI lineage solution described in this post is designed to help you manage your organization’s AMI hierarchy and lifecycle, including tracking AMI origins and usage throughout its AWS environment. By implementing this solution, your security teams can quickly understand the scope of impact when security vulnerabilities are discovered, help ensure compliance with organizational policies, and maintain better visibility into their AMI estate.
The solution in this blog post uses Amazon Neptune, a high-performance graph database, along with native AWS security services to maintain a comprehensive view of AMI relationships and enable proactive security monitoring. With the solution in place, you can enforce controls on AMI sourcing, including validation of marketplace AMIs through service control policies (SCPs), and maintain compliance with organizational and regulatory requirements throughout the AMI lifecycle.
AMI Lineage provides a comprehensive governance solution that uses AWS security services and Neptune to create and maintain a hierarchical graph representation of their AMI relationships. This solution helps security and compliance teams understand the complete history of their AMIs including where they originated from, enforce organizational policies such as requiring all AMIs to be encrypted, and rapidly assess security impacts across their organization.
The solution integrates core AWS services with security and governance capabilities. The core components of the solution in the security tooling account are:
CreateImage, CopyImage, DeregisterImage), evaluate them against compliance rules, and update the Neptune graph database. The functions are configured with least-privilege AWS Identity and Access Management (IAM) permissions to enhance security.From a governance perspective, this solution provides comprehensive AMI origin validation to help ensure AMIs come from approved sources, including the validation of AWS Marketplace AMIs against a list of trusted vendors. Lifecycle management capabilities enforce AMI retention policies and deprecation processes. Compliance monitoring tracks adherence to organizational and regulatory requirements, while security event scope assessment capabilities quickly identify affected resources when security vulnerabilities are discovered. A detailed audit trail maintains a complete history of AMI creation, modification, and usage patterns.
The AMI Lineage solution follows AWS security best practices with a multi-account deployment architecture designed to maximize security while maintaining operational efficiency. The architecture distributes responsibilities across three primary account types: an organization management account, a centralized security tooling account, and multiple member accounts.
This architectural approach helps ensure that sensitive operations and data remain centralized in the security tooling account while enabling distributed monitoring and policy enforcement across the organization. The clear separation of concerns enhances security while maintaining the scalability needed for large-scale AWS deployments.
Figure 1: AMI Lineage solution architecture and workflow
The workflow and architecture shown in figure one includes the following:
CreateImage or CopyImage) occurs in a member account, a local Amazon EventBridge rule captures it.The organization management account serves as the central control point for policy enforcement and organizational oversight. This account hosts SCPs that prevent non-approved AMI usage across the organization and manages organization-wide EventBridge rules that capture AMI events from member accounts. Cross-account trust policies configured in this account enable secure communication between the management account and the security tooling account.
Additionally, the management account establishes Security Hub in delegated administrator mode, designating the security tooling account as the centralized security administrator for the organization. From the security tooling account, Security Hub can be then configured to aggregate all Regions down to one core Region for easier evaluation by security personnel.
The security tooling account acts as the central hub for AMI lineage processing and storage. This account hosts the Neptune graph database cluster with encrypted storage, helping to ensure that AMI relationship data is securely maintained. Lambda functions running in this account process events, handle API requests, and evaluate compliance with least-privilege permissions. API Gateway provides secure REST endpoints for lineage queries and security assessments. Security Hub custom insights and findings are centralized here in the security tooling account as the Security Hub delegated administrator account, along with Amazon Simple Notification Service (Amazon SNS) topics for notifications and alerts. The Amazon Virtual Private Cloud (Amazon VPC) infrastructure supporting these services is also deployed in the security tooling account, providing network-level isolation and security.
The solution enables distributed monitoring and enforcement by deploying lightweight components into each member account across the organization. Each member account includes AWS Config rules for continuous compliance monitoring, cross-account IAM roles to enable secure access from the security tooling account, and local EventBridge rules that forward AMI-related events to the central processing system.
Security and compliance integration extends throughout the solution. IAM manages least-privilege access control and permissions across components. AWS CloudTrail records API activity for audit trails and compliance reporting, while Security Hub centralizes security findings and compliance status across your AMI estate. GuardDuty provides threat detection for AMI-related activities. SCPs enforce organization-wide controls on AMI creation and usage patterns, and AWS Config tracks AMI configuration changes and evaluates compliance rules.
The AMI Lineage solution operates through a continuous monitoring and automated response system that maintains comprehensive visibility into your AMI landscape. When AMI lifecycle events occur in your organization, EventBridge rules capture these activities, including creation, copying, modification, and deregistration events. Lambda functions in the security tooling account are then called upon to process these events with appropriate security controls and update the Neptune graph database in real-time, while CloudTrail logs provide a comprehensive audit trail of AMI-related activities.
The system tracks critical security and compliance metadata that forms the foundation of effective AMI governance. This includes:
Security teams use this comprehensive data through secure API calls to visualize complete AMI hierarchies and relationships, providing clear insight into how AMIs are related across your infrastructure. The compliance of your AMI estate is continuously tracked through a combination of services:
The solution provides robust automated policy enforcement capabilities that operate continuously to maintain security and compliance. The system helps ensure that only approved AMIs with verified lineage history can be used to launch new instances, automatically blocking attempts to use non-compliant images. SCP controls on AMI creation and usage are enforced organization-wide, preventing unauthorized AMI operations before they can impact your environment. When policy violations are detected, the system can trigger automated responses to security events and maintain compliance with organizational standards through real-time enforcement.
Before deploying the AMI Lineage solution, you need to establish the proper security and governance foundation across your organization. Your AWS Organizations management account requires administrative permissions, and your organization must be enabled with all features to support the policies used in this solution. You will also need a dedicated security tooling account to host the solution’s core components, with cross-account IAM roles configured to allow secure access. Finally, essential security services must be configured at the organization level, including Security Hub, CloudTrail organization trails for audit logging, and encryption keys using AWS Key Management Service (AWS KMS) for data protection.
From a technical perspective, ensure you have Python 3.8 or later installed if deploying from a local environment, along with AWS Command Line Interface (AWS CLI) version 2 installed and configured with appropriate security credentials. You’ll also need an Amazon Simple Storage Service (Amazon S3) bucket for deployment artifacts, encrypted using SSE-KMS with a customer-managed key to align with best practices for protecting deployment assets.
The complete AMI Lineage solution is available as open source code in the AWS Samples repository. You can clone the repository and follow the deployment instructions. The repository includes the necessary AWS CloudFormation templates, Lambda functions, and deployment scripts referenced in the following phases.
The deployment process follows a five-phase approach that builds security and compliance capabilities progressively:
The first phase establishes the security foundation by configuring AWS Organizations security services. This involves enablingSecurity Hub in the management account and designating the security tooling account as the delegated administrator, enablingnullGuardDuty with the security tooling account configured as thenulldelegated administrator, and enabling an organizational wide CloudTrail trail for audit logging.
The second phase deploys base security controls through organization-wide SCPs. These policies enforce AMI governance controls by preventing the use of non-approved AMIs and helping to ensure that proper tagging and approval workflows are followed.
The third phase deploys organization-wide EventBridge rules from the management account to capture AMI events across member accounts and forward them to the security tooling account for processing. These rules listen for specific API calls captured by CloudTrail.
An example of the event pattern used to capture CreateImage and CopyImage events looks like this:
The fourth phase focuses on core infrastructure deployment in the security tooling account. This is where the primary processing and storage components are deployed, following security best practices by centralizing sensitive operations in a dedicated account.
This deployment script handles multiple components in the security tooling account. The Neptune cluster deployment includes encryption and VPC configuration to help ensure secure storage and access to AMI lineage data. Lambda functions are deployed with security controls and configured with VPC attachment, which allows for secure Neptune access in the VPC, appropriate IAM roles with least-privilege permissions, and environment variables for secure configuration. API Gateway provides secure REST endpoints for external access to AMI lineage data and security assessments.
The fifth phase establishes comprehensive compliance and monitoring capabilities across member accounts. AWS Config rules are deployed to continuously monitor AMI compliance across your organization, while EventBridge rules forward AMI events to the central processing system.
After deployment, thorough verification helps ensure that security configurations are properly implemented. This includes validating IAM permissions to help ensure least-privilege access, testing security controls to verify SCP enforcement, validating encryption settings acrosscomponents, and confirming that the security tooling account is properly configured as the Security Hub delegated administrator.
When deployed, AMI Lineage provides security operations and compliance monitoring capabilities through its API hosted in the security tooling account and automated monitoring systems. Security teams can query and receive complete AMI security relationships to understand the full context of AMIs in their environment.
When investigating AMIs, the system provides detailed security context including source validation information that confirms:
For security impact assessments, such as when a new CVE is discovered, the solution provides a powerful scope of impact analysis. By querying the API with a specific finding, security teams can rapidly determine every affected resource across their entire organization that stems from a compromised or vulnerable AMI. Using that information, they can understand the full scope of their exposure and begin remediation. See Security best practices in Amazon API Gateway for helpful considerations while using API Keys.
This analysis returns impact information including:
Compliance monitoring operates continuously through automated assessment capabilities that evaluate your AMI estate against organizational policies and regulatory requirements. Teams can generate comprehensive compliance reports that show adherence to security standards across their entire infrastructure.
The solution provides security automation and remediation through configurable automated responses to security events. Security Hub, operating in delegated administrator mode from the security tooling account, can be configured to automatically respond to findings by stopping instances using AMIs with critical vulnerabilities, quarantining instances launched from unapproved sources, and sending immediate notifications for high-severity findings.
Security visualization and reporting capabilities, centralized in the security tooling account, provide real-time dashboards showing:
For security investigations and audit purposes, the solution maintains a queryable audit trail that provides a complete history of AMIs, including creation and modification events, security scanning results and findings, approval workflow history, and compliance status changes over time.
To decommission the AMI Lineage solution, use the following steps to prevent dependency errors. The process is the reverse of the deployment.
In this blog post, we showed you how you can use the AMI Lineage solution to build a comprehensive approach to tracking the complete history of your AMIs from creation to decommissioning. By storing this data in an Amazon Neptune graph database, you can build a hierarchical view of the relationships between your EC2 instances and the AMIs they were launched from. You learned how that data can be used to improve security response and remediation and assist in auditing and compliance activities.
The solution uses AWS Organizations to provide preventative controls to help ensure that only approved AMIs are used and integrates AWS security services like Amazon GuardDuty, AWS Security Hub, and AWS Config to add additional layers of security monitoring and management. Finally, you saw how the solution can be used during a security event or when new CVEs are published, so that you can rapidly discover which systems are affected and automate responses based on those findings.
While this solution provides powerful capabilities, it’s important to consider the operational and cost aspects. The core components, particularly Neptune, have associated costs that will scale with the size of your AMI estate. We recommend implementing cost monitoring and alerts as part of your deployment. Furthermore, because the solution is event-driven, you should plan a one-time backfill process to ingest your organization’s existing AMI history into the graph database. For organizations that require this level of granular control and visibility, these operational considerations are offset by the significant gains in security posture and compliance automation.
AMI Lineage transforms AMI governance from a manual, error-prone process into an automated, comprehensive security capability that scales with your organization’s growth. By implementing this solution, your organization can gain the visibility, control, and automated response capabilities needed to maintain a strong security posture while enabling rapid, secure deployment of infrastructure across its AWS environment.
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.
Post Syndicated from Crosstalk Solutions original https://www.youtube.com/watch?v=P_wt-2P-WBk
Post Syndicated from Carie Fisher original https://github.blog/ai-and-ml/github-copilot/continuous-ai-for-accessibility-how-github-transforms-feedback-into-inclusion/
For years, accessibility feedback at GitHub didn’t have a clear place to go.
Unlike typical product feedback, accessibility issues don’t belong to any single team—they cut across the entire ecosystem. For example, a screen reader user might report a broken workflow that touches navigation, authentication, and settings. A keyboard-only user might hit a trap in a shared component used across dozens of pages. A low vision user might flag a color contrast issue that affects every surface using a shared design element. No single team owns any of these problems—but every one of them blocks a real person.
These reports require coordination that our existing processes weren’t originally built for. Feedback was often scattered across backlogs, bugs lingered without owners, and users followed up to silence. Improvements were often promised for a mythical “phase two” that rarely materialized.
We knew we needed to change this. But before we could build something better, we had to lay the groundwork—centralizing scattered reports, creating templates, and triaging years of backlog. Only once we had that foundation in place could we ask: How can AI make this easier?
The answer was an internal workflow, powered by GitHub Actions, GitHub Copilot, and GitHub Models, that ensures every piece of user and customer feedback becomes a tracked, prioritized issue. When someone reports an accessibility barrier, their feedback is captured, reviewed, and followed through until it’s addressed. We didn’t want AI to replace human judgment—we wanted it to handle repetitive work so humans could focus on fixing the software.
This is how we went from chaos to a system where every piece of accessibility feedback is tracked, prioritized, and acted on—not eventually, but continuously.
Continuous AI for accessibility weaves inclusion into the fabric of software development. It’s not a single product or a one-time audit—it’s a living methodology that combines automation, artificial intelligence, and human expertise.
This philosophy connects directly to our support for the 2025 Global Accessibility Awareness Day (GAAD) pledge: strengthening accessibility across the open source ecosystem by ensuring user and customer feedback is routed to the right teams and translated into meaningful platform improvements.
The most important breakthroughs rarely come from code scanners—they come from listening to real people. But listening at scale is hard, which is why we needed technology to help amplify those voices. We built a feedback workflow that functions less like a static ticketing system and more like a dynamic engine—leveraging GitHub products to clarify, structure, and track user and customer feedback, turning it into implementation-ready solutions.
Before jumping into solutions, we stepped back to understand who this system needed to serve:
With these personas in mind, we knew we wanted to 1) treat feedback as data flowing through a pipeline and 2) build a system able to evolve with us.
With that foundation set, we built an architecture around an event-driven pattern, where each step triggers a GitHub Action that orchestrates what comes next—ensuring consistent handling no matter where the feedback originates. We built this system largely by hand starting in mid-2024. Today, tools like Agentic Workflows let you create GitHub Actions using natural language—meaning this kind of system could be built in a fraction of the time.
The workflow reacts to key events: Issue creation launches GitHub Copilot analysis via the GitHub Models API, status changes initiate hand-offs between teams, and resolution triggers submitter follow-up with the user. Every Action can also be triggered manually or re-run as needed—automation covers the common path, while humans can step in at any point.
Feedback isn’t just captured—it continuously flows through the right channels, providing visibility, structure, and actionability at every stage.
*Click images to enlarge.

Feedback can come from anywhere—support tickets, social media posts, email, direct outreach—but most users choose the GitHub accessibility discussion board. It’s where they can work together and build community around shared experiences. Today, 90% of the accessibility feedback flows through that single channel. Because posts are public, other users can confirm the problem, add context, or suggest workarounds—so issues often arrive with richer detail than a support ticket ever could. Regardless of the source, every piece of feedback gets acknowledged within five business days, and even feedback we can’t act on gets a response pointing to helpful resources.
When feedback requires action from internal teams, a team member manually creates a tracking issue using our custom accessibility feedback issue template. Issue templates are pre-defined forms that standardize how information is collected when opening a new issue. The template captures the initial context—what the user reported, where it came from, and which components are involved—so nothing is lost between intake and triage.
This is where automation kicks in. Creating the issue triggers a GitHub Action that engages GitHub Copilot, and a second Action adds the issue to a project board, providing a centralized view of current status, surfacing trends, and helping identify emerging needs.

With the tracking issue created, a GitHub Action workflow programmatically calls the GitHub Models API to analyze the report. We chose stored prompts over model fine-tuning so that anyone on the team can update the AI’s behavior through a pull request—no retraining pipeline, no specialized ML knowledge required.
We configured GitHub Copilot using custom instructions developed by our accessibility subject matter experts. Our prompt serves two roles: triage analysis, which classifies issues by WCAG violation, severity, and affected user group, and accessibility coaching, where GitHub Copilot acts as a subject-matter expert to help teams write and review accessible code.
These instruction files point to our accessibility policies, component library, and internal documentation that details how we interpret and apply WCAG success criteria. When our standards evolve, the team updates the markdown and instruction files via pull request—the AI’s behavior changes with the next run, not the next training cycle. For a detailed walkthrough of this approach, see our guide on optimizing GitHub Copilot custom instructions for accessibility.
The automation works in two steps. First, an Action fires on issue creation and triggers GitHub Copilot to analyze the report. GitHub Copilot populates approximately 80% of the issue’s metadata automatically—over 40 data points including issue type, user segment, original source, affected components, and enough context to understand the user’s experience. The remaining 20% requires manual input from the team member. GitHub Copilot then posts a comment on the issue containing:
Then a second Action fires on that comment, parses the response, applies labels based on the severity GitHub Copilot assigned, updates the issue’s status on the project board, and assigns it to the submitter for review.
If GitHub Copilot’s analysis seems off, anyone can flag it by opening an issue describing what it got wrong and what it should have said—feeding directly into our continuous improvement process.

Before we act on GitHub Copilot’s recommendations, two layers of review happen—starting with the issue submitter.
The submitter attempts to replicate the problem the user reported. The checklist GitHub Copilot provides in its comment guides our community managers, support agents, and sales reps through expert-level testing procedures—no accessibility expertise required. Each item includes plain-language explanations, step-by-step instructions, and links to tools and documentation.
Example questions include:
alt attribute describe the image’s purpose, or is it a generic file name?If the submitter can replicate the problem, they mark the issue as reviewed, which triggers the next GitHub Action. If they can’t reproduce it, they reach out to the user for more details. Once new information arrives, the submitter can re-run the GitHub Copilot analysis—either by manually triggering the Action from the Actions tab or by removing and re-adding the relevant label to kick it off automatically. AI provides the draft, but humans provide the verification.

Once the submitter marks the issue as reviewed, a GitHub Action updates its status on the workflow project board and adds it to a separate accessibility first responder board. This alerts the accessibility team—engineers, designers, champions, testing vendors, and managers—that GitHub Copilot’s analysis is ready for their review.
The team validates GitHub Copilot’s analysis—checking the severity level, WCAG mapping, and category labels—and corrects anything the AI got wrong. When there’s a discrepancy, we assume the human is correct. We log these corrections and use them to refine the prompt files, improving future accuracy.
Once validated, the team determines the resolution approach:
With a path forward set, the team marks the issue as triaged. An Action then reassigns it to the submitter, who communicates the plan to the user—letting them know what’s being done and what to expect.

As part of the review process, the team connects user and customer feedback to our formal accessibility audit system.
Roughly 75–80% of the time, reported issues correspond to something we already know about from internal audits. Instead of creating duplicates, we find the existing internal audit issue and add a customer-reported label. This lets us prioritize based on real-world impact—a sev2 issue might technically be less critical than a sev1, but if multiple users are reporting it, we bump up its priority.
If the feedback reveals something new, we create a new audit issue and link it to the tracking issue.

This is the most critical step for trust. Users who take the time to report accessibility barriers deserve to know their feedback led to action.
Once a resolution path is set, the submitter reaches out to the original user to let them know the plan—what’s being fixed, and what to expect. When the fix ships, the submitter follows up again and asks the user to test it. Because most issues originate from the community discussion board, we post confirmations there for everyone to see.
If the user confirms the fix works, we close the tracking issue. If the fix doesn’t fully address the problem, the submitter gathers more details and the process loops back to the accessibility team review. We don’t close issues until the user confirms the fix works for them.

The workflow doesn’t end when an issue closes—it feeds back into itself.
When submitters or accessibility team members spot inaccuracies in GitHub Copilot’s output, they open a new issue requesting a review of the results. Every GitHub Copilot analysis comment includes a link to create this issue at the bottom, so the feedback loop is built into the workflow itself. The team reviews the inaccuracy, and the correction becomes a pull request to the custom instruction and prompt files described earlier.
We also automate the integration of new accessibility guidance. A separate GitHub Action scans our internal accessibility guide repository weekly and incorporates changes into GitHub Copilot’s custom instructions automatically.
The goal isn’t perfection—it’s continuous improvement. Each quarter, we review accuracy metrics and refine our instructions. These reviews feed into quarterly and fiscal year reports that track resolution times, WCAG failure patterns, and feedback volume trends—giving leadership visibility into both progress and persistent gaps. The system gets smarter over time, and now we have the data to show it.

A year ago, nearly half of accessibility feedback sat unresolved for over 300 days. Today, that backlog isn’t just smaller—it’s gone. And the improvements don’t stop there.
We track this through automated weekly and quarterly reports generated by GitHub Actions—surfacing which WCAG criteria fail most often and how resolution times trend over time.
A user named James emailed us to report that the GitHub Copilot CLI was inaccessible. Decorative formatting created noise for screen readers, and interactive elements were impossible to navigate.
A team member created a tracking issue. Within moments, GitHub Copilot analyzed the report—mapping James’s description to specific technical concepts, linking to internal documentation, and providing reproduction steps so the submitter could experience the product exactly as James did.
With that context, the team member realized our engineering team had already shipped accessible CLI updates earlier in the year—James simply wasn’t aware.
They replied immediately. His response? “Thanks for pointing out the –screen-reader mode, which I think will help massively.”
Because the AI workflow identified the problem correctly, we turned a frustration into a resolution in hours.
But the most rewarding result isn’t the speed—it’s the feedback from users. Not just that we responded, but that the fixes actually worked for them:
That independence is the point. Every workflow, every automation, every review—it all exists so moments like these are the expectation, not the exception.
Stories like these remind us why the foundation matters. Design annotations, code scanners, accessibility champions, and testing with people with disabilities—these aren’t replaced by AI. They are what make AI-assisted workflows effective. Without that human foundation, AI is just a faster way to miss the point.
We’re still learning, and the system is still evolving. But every piece of feedback teaches us something, and that knowledge now flows continuously back to our team, our users, and the tools we build.
If you maintain a repository—whether it’s a massive enterprise project or a weekend open-source library—you can build this kind of system today. Start small. Create an issue template for accessibility. Add a .github/copilot-instructions.md file with your team’s accessibility standards. Let AI handle the triage and formatting so your team can focus on what really matters: writing more inclusive code.
And if you hit an accessibility barrier while using GitHub, please share your feedback. It won’t disappear into a backlog. We’re listening—and now we have the system to follow through.
The post Continuous AI for accessibility: How GitHub transforms feedback into inclusion appeared first on The GitHub Blog.
Post Syndicated from LastWeekTonight original https://www.youtube.com/shorts/SnE6drdrRvU
Post Syndicated from corbet original https://lwn.net/Articles/1062163/
One of the first changes merged for the upcoming 7.0 release was nullfs,
an empty filesystem that cannot actually contain any files. One might
logically wonder why the kernel would need such a thing. It turns out,
though, that there are places where a null filesystem can come in handy.
For 7.0, nullfs will be used to make life a bit easier for init
programs; future releases will likely use nullfs to increase the isolation
of kernel threads from the init process.
Post Syndicated from The Atlantic original https://www.youtube.com/shorts/WS7IZAZbsTw
Post Syndicated from The Hook Up original https://www.youtube.com/watch?v=SKW2IIaLp_4
Post Syndicated from jzb original https://lwn.net/Articles/1062575/
Sasha Levin has announced the release of the 6.19.7 and 6.18.17 stable kernels. As usual, each
contains important fixes throughout the tree; users are advised to
upgrade.
Post Syndicated from jzb original https://lwn.net/Articles/1062570/
Security updates have been issued by AlmaLinux (gimp, git-lfs, grafana-pcp, kernel, mysql8.4, nfs-utils, opentelemetry-collector, osbuild-composer, postgresql:16, and python3.12), Debian (imagemagick and netty), Fedora (dr_libs and python-lxml-html-clean), Slackware (libarchive and libxml2), SUSE (busybox, coredns, firefox, freerdp, ghostty, gnutls, go1.25, go1.26, GraphicsMagick, grype, helm, helm3, ImageMagick, perl-Compress-Raw-Zlib, python, python311-lxml_html_clean, python311-PyPDF2, tomcat11, and traefik), and Ubuntu (curl, gimp, and libpng).
Post Syndicated from The Metasploit Team original https://www.rapid7.com/blog/post/pt-announcing-metasploit-pro-5-penetration-testing-evolving
The role and demand for red-teaming capabilities are growing, as more exploitable CVEs make their way into criminal hands. Being proactive is no longer a capability that can be reserved for annual tests, but a continuous assessment to determine exposure and even through the validation of an organization’s security posture. With this in mind, we are delighted to announce the long awaited availability of Metasploit Pro 5.0.0 – which is not just an update, but a fundamentally new approach to red-teaming, designed with the sole intention of staying ahead of ever-increasingly capable threat actors.
Amongst the multitude of changes, Metasploit 5.0.0 offers an intuitive testing workflow that removes the ever evolving complexity of testing, as well as a suite of powerful new modules and critical enhancements. This is the version you can’t afford to miss. For all the technical details, the granular release notes can be viewed here.
Say goodbye to complexity, as Metasploit Pro has completely overhauled the testing workflow. Updates are highlighted by an intuitive user interface, ensuring that your focus remains on high-value penetration testing and vulnerability validation, not fighting the interface. These changes are the foundation for the future, preserving the core functionality you rely on while enabling even more powerful features down the road.

⠀
Stop guessing and start seeing. The new implementation of Network Topology support provides instant, crystal-clear clarity on hosts that have been compromised, have associated cracked credentials, or captured data. For enterprise environments with vast, complex surfaces, we’ve invested in performance improvements, giving you the power to zoom and pan through hundreds of available hosts with zero lag. This is actionable visualization that transforms data into defense.

⠀
Get the necessary assurance before you click ‘run.’ Metasploit modules can now register crucial vulnerability detection details as part of running. This means that modules capable of running pre-check detection logic give you the full intelligence picture before you attempt exploitation. This new level of transparency and detail empowers you to make smarter, faster decisions, saving you precious time and minimizing the chance of failed module runs and adverse side effects.

⠀
Unleash your inner expert with unprecedented control and efficiency. Advanced users of Metasploit Pro will immediately benefit from multiple UX improvements to the single module run page. Tired of manually configuring options? Users now receive intelligent suggestions for applicable values, including network targets, Kerberos credential cache files, and more – streamlining ADCS workflows.

⠀
Furthermore, you now have the ability to manually choose and configure individual payloads, giving you the final word on how you exploit targets. Metasploit Pro will continue to default to the most common payload for each exploit.
Plus, new quality-of-life improvements for replaying module runs ensure that verifying remediation and re-exploiting targets is a seamless, one-click process. Gone are the days of reconfiguring an entire module run to change a single option. The old list view has also been updated to include the ability to view the module option details that a module was run with. These capabilities can additionally be leveraged by advanced users who are interacting with Metasploit Pro in a programmatic fashion or through the command line interface to see exactly how Metasploit Pro is running modules.

⠀
Finally, boost your team’s collaboration with the new session tagging feature. Sessions can now be tagged to facilitate advanced and coordinated post-exploitation workflows. Team members can apply instant, custom tags to track status and flag arbitrary qualities, which significantly improves coordination and organization across multi-person engagements.
Tackle one of the most critical attack vectors in modern networks: Metasploit continues its relentless investment in modern exploitation techniques with the groundbreaking updates to the AD CS Workflows Metamodule. This powerful new feature is a significant advancement, providing security professionals with an automated, comprehensive approach to identifying and leveraging nine common AD CS vulnerabilities.
Now we’ve taken it even further, with new support for the latest and most dangerous ESC flaws: ESC9, ESC10, and ESC16. Take back control of your Active Directory environment and neutralize these threats with surgical precision. For detailed configuration instructions and comprehensive feature documentation, visit our AD CS Workflows MetaModule documentation.

⠀
In fast-moving operations, context can disappear quickly as new sessions come online and analysts shift between tasks. Session tagging brings clarity back to your workflow by letting you attach meaningful labels to every open session. Instead of relying on IPs or hostnames alone, you can tag sessions with identifiers that matter to your team – such as priority, environment, or role – making it easy to group related systems and instantly recognize high-value targets.

⠀
Metasploit Pro now incorporates SAML Single Sign-On (SSO) authentication, providing your team with a simple, unified login experience. By connecting to your centralized directory, users can access Metasploit Pro with the same credentials they use for all other major applications. Administrators can easily configure their identity provider (IDP) to enable a passwordless workflow and utilize existing Multi-Factor Authentication (MFA) services, making access quick, consistent, and part of your standard corporate flow.
These features are available in Metasploit Pro 5.0.0 onwards. We’re also proud to collaborate with our customers, who are often the source of inspiration for product evolution. Ideas for improvements or enhancements can be shared with our Support team to help you refine the idea, then submit it to our Product team on your behalf.
Rapid7 Labs launched a podcast today! Episode 1 of ‘Hacktics & Telemetry’ is now live on Rapid7’s YouTube page. Alongside some expert commentary on emergent threats and an exciting guest spot, the final segment is all about Metasploit Pro 5.0.0. Dive into our official companion blog here, and find the full episode embedded below.
⠀
Post Syndicated from Douglas McKee original https://www.rapid7.com/blog/post/tr-introducing-hacktics-telemetry-podcast-rapid7-labs
If you spend your days building, shipping, defending, or fixing systems, you already know how this goes. A new technique shows up in a research thread, someone drops a “has anyone checked if we’re exposed?” comment, and suddenly you’re juggling risk, patches, logging gaps, and whatever tool is in the blast radius this week.
That day-to-day reality is why Rapid7 Labs is launching Hacktics and Telemetry, a bi-weekly video and audio podcast with episodes built to fit into a lunch break or a commute. It’s hosted by Rapid7’s Douglas McKee, bringing to the pod years of deep technical and leadership experience, then co-hosted by Jonah ‘CryptoCat’ Burgess – a strong researcher with a solid pulse on the cybersecurity community.
The format stays consistent on purpose. Each episode starts with a scan of what’s emerging, shifts into a guest conversation, then closes with a short segment that ties the story back to mitigation and tooling. The goal is simple: move past theory, show what’s happening with real examples, and leave you with something you can act on.
Doug and Jonah open by digging into two AI-centric stories from the past week. The first is PhoneLeak, described as data exfiltration in Gemini via phone call. It’s the kind of uncomfortable example that forces practical questions: how do you defend against mobile clickjacking when it’s disguised as a routine CAPTCHA? When an AI assistant has deep extensions into a user’s workspace, how do you prevent malicious prompts from quietly accessing sensitive data like 2FA codes? And perhaps most importantly, how do defenders anticipate and monitor for bizarre, out-of-the-box exfiltration methods—like an AI bypassing SMS confirmations to leak data via DTMF tones on a phone call?
The second story comes from the other side of the AI conversation: an AI agent reportedly identifying an RCE in BeyondTrust remote support, plus discussion of older privileged remote access versions. More automation can mean faster discovery, which shrinks the window between “interesting finding” and “you need to patch this.” That changes how defenders think about exposure, patch prioritization, and what “good enough” means (and looks like) when it comes to monitoring.
In the guest segment, Greg Richardson (Global Advisory CISO & AI Thought Leader, 6 Levers AI) walks through how he uses AI agents in his workflow while keeping control tight. He talks about setting tasks while he sleeps, but the constraints are the point: access is locked down, the agent only touches files he explicitly provides, communication is limited, and token limits help cap the size of any mistake. He also makes a strong case for starting small, with one task at a time, instead of trying to automate dozens of things on day one.
To close out this inaugural episode, the team hits on a SolarWinds Help Desk vulnerability, then shares a quick look at Metasploit Pro 5.0 updates – including more granular payload selection and a walkthrough of the new UI.
If your idea of useful content includes threat trade-offs, concrete mitigations, and a bit of candid “how this actually plays out,” you’re in the right place.
Catch the full episode below:
⠀
Post Syndicated from Боян Юруков original https://yurukov.net/blog/2026/iz2026-aktivnost/

Минаха 6 дни от началото на кампанията за събиране на заявления за гласуване в чужбина за изборите на 19-ти април. Писах за формуляра за подаване на заявления и съвети за попълването му на 6-ти март. Седмица по-рано описах защо сега за разлика от последните няколко години подаването на заявления е от критично значение за отварянето на секции. Това се случва след промени в Изборния кодекс, които връщат правата и възможностите за гласуване на българите в чужбина години назад и създават излишни трудности както в организирането, така и в участието в изборния процес. Тъй като промените станаха буквално в последния момент, имаше несигурност дали ще има кандидати специално за район Чужбина, както и какъв ще е процеса за създаване на секциите. Вероятно затова отново имаше забавяне в публикуването на електронното заявление за гласуване от страна на ЦИК.
Както и предишни години следя активността по подаване на заявления на страницата на Glasuvam.org. Има карта и подробен списък отразяващ точно подадените заявления. Опитал съм се максимално да отразя и решението за автоматично одобрени секции. Имаше проблем с автоматичното следене на заявленията, но се реши. За първите 5 дни графиката на подадените заявления по часове е оценка на база активност предишни години и броя подадени в различни часове сега. На графиката виждате сравнение в светло синьо с активността на последния вот през октомври 2024-та.

Това, което следя също е активността по дни и я сравнявам с изборите през последните 10 години. Тук виждате броят събрани заявления по ден от започването на кампанията – т.е. публикуване на електронния формуляр. През 2024-та имаше доста ниска активност, тъй като доста от секциите бяха отворени автоматично и повечето хора не виждаха смисъл да подават заявления. През 2023-та, 2022-ра и ноември 2021-ва активността беше по-висока, включително на самия вот. Най-много заявления имаше през април и юли 2021-ва като през април имаше рекорден брой събрани в първия ден, както и общо през кампанията. Отговорност за това имаше както най-дългия срок за подаване до сега, така и много добрата координация и работа на доброволци и задгранични огранизации.
Сега виждаме, че събирането върви с добри темпове и се доближава до това през юли 2021-ва. На втората графика виждаме същите данни, но с оставащи дни до крайния срок. Там също се вижда, че въпреки късния старт – едва 19-дни преди срока от 24-ти март – събирането на заявления изпреварва кампаниите от предходните години.


Великобритания, където българите бяха сред най-засегнатите от органиченията в пробмените на Изборния кодекс, показват най-голяма активност. Вижда се, че събирането върви със същите темпове както през юли 2021-ва и изпреварва в пъти събраните заявления две седмици преди крайния срок.

В Германия, където е навярно най-голямата българска диаспора, също има висока активност въпреки, че голям брой секции ще бъдат отворени автоматично както и предишни години. При липса на други променливи, това може да е индикация за значително по-висок интерес към участие в изборите от предходните години. Т.е. може да е индикатор за по-висока изборна активност поне сред сънародниците ни в чужбина, на които мнозинството в този парламент практичесни позволява физически да гласуват.

Събирането на заявления в Турция винаги е показвала различна крива на активност от другите държави. Този път в началото се виждаше липсва на заявления напомнящо на 2017-та, когато десет дни почти никой не подаваше такива. На 4-тия ден обаче се активизираха и вече се движи аналогично на събирането на заявления на последния вот. Общият им брой обаче е сред най-ниския на този етап от кампанията, както и спрямо оставащото време, както се вижда на следващите две графики. Данните за 2026-та са е синьо.
Това е странно предвид, че по подобие на Великобритания не само броят секции е ограничен, но и изрично трябва да се подават заявления, за да е възможно отварянето им, тъй като автоматичното одобрение беше оставено само в рамките на ЕС.


Ако вземем данните за всички други държави освен Турция виждаме, че активността на събиране е идентична с тази от юли 2021-ва.

Предвид късния старт и при липса на промяна в динамиката очаквам поне 55 хиляди заявления. Сравнил съм броя заявления събирани по държави в последните 10 години и се вижда, че в Турция се подават между 18 и 28 хиляди на година. Тази година очаквам повече в горния край заради ограниченията. Кривата за активността в другите държави ми показва, че вероятно ще се повтори сценария от юли 2021-ва, когато под 40% от заявленията са в Турция. Ще разберем през следващите две седмици.

Електронния формуляр за заявления за гласуване в чужбина ще намерите на страницата на ЦИК.
Post Syndicated from The Atlantic original https://www.youtube.com/watch?v=S0wyBWv_b2U
Post Syndicated from Matt Granger original https://www.youtube.com/watch?v=bqqGFHMW39w
Post Syndicated from Дарина Сарелска original https://www.toest.bg/krayat-na-zhurnalistikata/

Журналистиката е на изчезване. Не ви го казвам аз. Казва го последното проучване на Института „Ройтерс“, което включва елита на новинарската индустрия в 51 държави по света.
Делът на песимистите за бъдещето на професията почти се е удвоил – от 10% през 2022 г. до 18% днес. Паралелно с това оптимизмът се срива – едва 38% от хората, които правят журналистика на най-високо ниво, казват, че професията ще има добро развитие в следващата година. Преди четири години този дял е бил около 60%.
Оптимизъм
Песимизъм
Разбира се, виновникът за всичко тези дни – изкуственият интелект. Но не само. И не защото роботи пишат новините, а защото роботи променят пътя на читателите до тях.
Вместо да кликат към медийни сайтове, все повече потребители стигат до информацията директно в търсачката, която им дава синтетично обобщение, сглобено от чуждо (често безплатно) съдържание. Издателите очакват трафикът от търсачки към новинарските сайтове да спадне с около 40% през следващите три години именно заради тези т.нар. zero-click търсения.
Преди
Сега
Има и друга причина – кризата на релевантност на традиционните медийни брандове, особено на комерсиалните. Години наред те се опитваха да запазят бизнес модела си, лутайки се между страх и неразбиране на социалните мрежи и опита да ги използват като прокси – вход към собствените си платформи, където да монетизират вниманието на аудиторията. Само че през това време публиката тихо се премести другаде, а порасна и нова, която никога не се е информирала от друг екран освен от телефона. За нея „телевизорът“ е YouTube, Instagram и TikTok.
Тук вече говорим за нещо по-дълбоко от технологична промяна. Това е поколенческа и екзистенциална криза.
Политиците също успешно „помагат“ в делегитимирането на новинарските медии. Дали като ги приласкават и подкупват, дали като им викат fake news и мисирки, или просто като ги маргинализират чрез заобикаляне. Могат да си го позволят, защото социалните мрежи им дават достъп до същата, а понякога и до по-голяма публика без досадния посредник журналист, който прекъсва с въпроси. Не дай боже, критични. Или коригира твърдения. Често лъжливи.

Телевизионният фолклор пази спомена за Бойко Борисов и неговата реплика, че идването му в сутрешния блок на Нова телевизия при Ани Цолова и Виктор Николаев (2013–2017) му се струвало като ходене на зъболекар. Не ти е приятно, но трябва.
Сега вече не трябва.
Днес, макар да не е премиер, той има над 300 000 последователи във Facebook и понякога достига до 2 милиона гледания на клипче.
За сравнение: една рейтинг точка в България е около 70 000 души в общата демографска група – т.нар. 4+ (от 4 години нагоре), а сутрешните блокове в последните поне 15 години рядко правят повече от 4–5 рейтинг точки – дори и в най-добрите си времена. Сметката е проста: 300 000 гледания в най-добрия случай, ако станеш рано и отидеш до „телевизора“. А като се има предвид, че Facebook е предпочитаният източник за новини на българите, наравно с телевизиите, наистина не разбирам защо човек трябва да слага костюм и от кръста надолу и да бие път до близки и далечни студиа, за да му прекъсват мисълта.
Но това, струва ми се, е по-неуспешната стратегия за умъртвяване на журналистиката. Защото е твърде груба, твърде публична, а и успехът е често пирова победа. Все пак, каквото и да казват рейтингите, ясно е, че никой не гледа това, което в момента дават сутрин по bTV. Има и контрареакция, която дори и пренебрежимо малка, за да създаде реален бизнес проблем, e достатъчно голяма, за да създаде криза на влиянието. Не е удобно, когато в собствения ти ефир през ден ти повтарят, че си изпълнил политическа поръчка, включително собствените ти гости, дошли да се възползват от твоята публика, но и да ѝ отбележат, че седи на пресен гроб.
И да, това не е възпряло хората да си гледат „Ергенът“.
За сравнение, когато ABC се опитаха да спрат Джими Кимъл миналата есен и публиката възприе това като политически мотивирано решение под натиска на консервативни лидери и медии, реакцията беше 7 милиона отказали се от стрийминг услугите на компанията (Disney+ и Hulu). Седем милиона. Това е около един на всеки 30 потребители. И да, при платформи гиганти това не звучи като фатален удар. Но когато загубата се случи за няколко дни, дори и многомилиардни корпорации си взeмат бележка. Кимъл беше върнат на екран, а първият му епизод след прекъсването записа рекордна гледаемост.

Тук нямаме такава бурна обществена реакция.
Но пък на принципа на снежната топка натрупващите се случаи на обезглавяване на журналистиката година след година доведоха до качествени изменения. За първи път миналата седмица новоизбран министър-председател, пък макар и служебен, избра за първото си програмно интервю не голям телевизионен ефир, а нишов интернет подкаст.
Гостуването на Гюров в „Бюрото на Константин Вълков“ дава ясен знак: големите политически процеси, включително и предизборните кампании, вече имат нов терен. И той е в интернет.
Особено младите и особено негласуващите. Те познават Юксел Кадриев като поет от Instagram, а за сутрешните блокове разбират, когато откъси от тях попаднат в клиповете на „Цанов НАПРЕД и НАГОРЕ“. Те не включват телевизора, освен на Netflix, и не познават лицата и имената от телевизионните студиа. Вероятно и Косьо Вълков не познават – той също идва от преддигиталната епоха. Но завоят е ясен.
Взе го и Бойко Борисов, който досега поне не показва да е загубил природно силните си медийни инстинкти. През януари, след дълго мълчание, той даде общо четири пространни интервюта. Макар при него миксът между традиционни и нови медии да беше по-балансиран между старите брандове, като „Капитал“ и bTV, и YouTube каналите на Явор Дачков и Мартин Карбовски.
Това изместване на голямата конкуренция от телевизията към интернет не е само български феномен. По света вече е стандарт. Най-гледаните политически разговори в САЩ през последните години не са телевизионни интервюта, а подкасти. Някои от тях – като на Джо Роган – достигат аудитория, сравнима с тази на национални телевизии. Голяма част от подкастите направиха възможна безапелационната победа на Тръмп, който видя потенциал в т.нар. manosphere – общо название за онлайн общности, форуми и инфлуенсъри, които обсъждат мъжествеността, отношенията между половете и ролята на мъжете в обществото, като в тези общности често се появяват мизогиния, конспиративни идеи и радикализиране на млади мъже. Знаме на маносферата в глобален мащаб е Андрю Тейт, в местен се опитват да бъдат хора като Киро Брейка. И резултатите са налице. В глобално проучване Gen Z се оказа най-консервативното от години насам, като 30% от младите мъже смятат, че жените трябва да им се подчиняват.
Но подобни формати не са само крайнодесни. Във Великобритания The Rest Is Politics събира милиони гледания и често задава дневния ред на политическия разговор в страната.

Хора, които се явяват нещо като продължение на журналистиката в дигиталната епоха. Понякога са бивши журналисти. Понякога просто харизматични коментатори. В много случаи аудиторията им вече е по-голяма от тази на традиционни редакции и те развиват собствена медийна екосистема, създавайки едновременно възможност и риск за журналистиката, каквато я познаваме.
Подреждат какво виждаме, кога го виждаме и колко често го виждаме.
Превръщат новините в директен, персонален канал към аудиторията.
Все по-често комуникират без журналистически посредник.
Публика
Журналистиката не изчезва, но губи монопола върху това кой обяснява света.
Това е криза не само на бизнес модел, а и на посредничество.
От една страна, нюзинфлуенсърите достигат до групи, които са завинаги загубени за традиционните медии. Вероятно стоят в основата на Gen Z активизма, залял площадите миналата година не само в България. За тези нови публики журналистиката не е институция, нито е система от правила и стриктни принципи за работа с информация.
В изследване на Pew Research потребителите очертават профила на идеалния нюзинфлуенсър така: да ми помага да разбирам актуалните събития и проблеми; да реагира бързо, когато нещо се случва; да е автентичен – разбирай, да говори от свое име или поне така да изглежда. „Да ме забавлява и да споделя моите ценности и мнения“ е важно в различна степен за 70% от анкетираните.
Сега сравнете това с ценностите на журналистическата професия и ще разберете откъде идва рискът на новия модел.
Единственото общо е целта – да информира и да разяснява социално значими процеси. При нужда – бързо. И с това приликите свършват. Докато журналистиката търси факти, тук нуждата е от споделени преживявания, мнения и ценности. Търси се общност, формирана на основата на емоционални сходства.
Докато от журналистите се очаква да се стремят към обективност и дистанцираност от всички страни, да се пазят да не стават част от историята, която представят, и да се стараят отчетливо да отделят мнение от факт, от инфлуенсърите се иска персонифицирано съдържание, което да забавлява и утвърждава. Докато в журналистиката конфликтът е норма и начин на мислене, в социалните мрежи той е белег за токсичност и води до блокиране и канселиране.
Освен това, за разлика от редакциите, инфлуенсърите рядко имат процес по проверка на фактите или задължение за поправяне на грешки. И когато съдържанието се движи от алгоритми, подсилващи емоцията и конфликта, изкушението да се гони тренд, който става вайръл, вместо най-постижимата версия на истината е огромно.
В политиката това води до вълна от мачопопулизъм. В медиите – до фен бази и парцелиране на публиката на твърди ядра на принципа свой–чужд. А онези „архивни“ журналисти, които отказват да се влеят в която и да било идеологическа ниша и продължават да бъдат критични към всяка власт и всяка идеология, в крайна сметка се оказват обречени да загубят всяка публика. Защото, както видяхме и по случая „Петрохан“,
Един тежък криминален случай отново и по болезнен за всички ни начин показа до каква степен държавата е абдикирала от основни свои функции, оставяйки гражданите си абсолютно уязвими: от образование, през защита на горите, до правораздаване и служби за сигурност. Когато доверието в институциите, призвани да търсят истината, практически липсва, Facebook неизбежно се превръща в министерство на истината, а три милиона следователи – в разследващи журналисти.
Хора, които едно интервю не са вземали през живота си, се надпреварват да дават съвети на Миролюба Бенатова, Генка Шикерова и Мария Черешева:
Напоследък си мисля, че наблюдаваме как в края на земния си път журналистиката изпълнява самоотвержено своята последна обществена функция – да обедини иначе необединими обществени групи. Едните харесват Украйна, другите ходят на 3 март с руско знаме. Едните харесват гей парада, другите – парада на традиционното българско семейство. Едните искат България винаги в Европа, другите – никога срещу Русия.
Свързва ги само едно.
А „гадовете“ са малцината останали нормални журналисти, които имат комбинацията от опит, гръбнак, познания и интегритет да пазят журналистиката от фенщината. И им се занимава с това. Казвам „малцина“ и мога да ги назова поименно – не са повече от 20. Признавам си, че имам специално отношение към тях. Като към защитен вид. Защото алтернативата е Андрю Тейт или Киро Брейка.
Баланс, стандарти и етика. Това, разбира се, са много важни категории в нашата професия. И извратени до пълната им антитеза в родните ни медийни условия. Не защото не са съществени, а защото в лицето на користни играчи и/или непрофесионалисти могат да бъдат прилагани, както дяволът чете евангелието. Или, за да съм по-конкретна – както българска прокуратура делото за КТБ.
Когато започна разследването срещу Делян Пеевски по Глобалния закон „Магнитски“ и се появиха първите данни, че може да му бъдат наложени санкции за корупция, ръководството на телевизията имаше сериозен проблем, че отразяваме темата. Подозирам, че проблемът е бил на някого извън телевизията. Но аргументите звучаха познато. Същите аргументи, които чуваме днес по казуса „Петрохан“.
„Това е неприключило производство.“
„Защо трябва да правите интервюта на парче?“
„Защо давате думата на адвокати на обвиняеми?“ (В онзи случай – Цветан Василев, който след фалирането на КТБ вече беше готов да говори срещу бившите си ортаци.)
„Къде е другата гледна точка?“ (Пеевски тогава все още не говореше пред асансьора.)
„Защо не изчакате разследването да приключи, да отиде някой до САЩ, да прочете всички тези документи, които се цитират като основание за санкциите, и тогава да направите журналистическо разследване?“
Ако бяхме следвали тези „професионални“ препоръки, вероятно и до днес нямаше да сме споменали темата „Магнитски“ в новините. Което, подозирам, е била и целта.
Но сега виждам същите аргументи от хора, с които довчера протестирахме в защита на Мария Цънцарова и свободата на журналистиката.
През годините съм стигала до един и същ извод:
Докато журналистиката защитава нашата кауза, тя е необходима. Когато обаче започне да задава неудобни въпроси на „нашите“ или срещу „нашите“, изведнъж се оказва проблем. Само че свободата на медиите има нужда от защита точно тогава, когато в търсене на истината стига до неудобни и непопулярни тези.
На ежедневна база журналистиката рови в неподреденото. Осветява ъгли на споделените ни обществени килери, които са непоносими, разхвърляни и често миришат или изглеждат неприятно.
И точно тогава ни трябва – за да ни води през тези неосветени коридори, докато се прояснят силуетите на истината срещу караконджулите на фалшивите новини, пропагандата, конспирацията и обикновения информационен хаос.

Защо прекъсва? Защо задава въпрос по няколко пъти? Защо работи по неразкрити престъпления? Защо понякога се движи по тънкия лед между интереса на малцина и нуждата за информираност на мнозина?
В Етичния кодекс на журналистите – този, който всички обичат да цитират, но малцина са чели – има няколко основни принципа.
Първият е:
Търси фактите и ги съобщавай.
Не „Търси фактите и ако се харесват на публиката, ги съобщавай“. Не е и „Търси фактите и ако са забавни, ги публикувай“.
Вторият е:
Минимизирай вредата.
Обърнете внимание – не е „Не вреди“. Вреди с мярка. Тоест професията допуска, че в процеса на търсене на истината неизбежно може да се стигне до вреда. Нашият стандарт е да направим най-голямото възможно добро за най-голям брой хора.
Това означава, че понякога ще задаваме въпроси, които връщат събеседниците ни на места, на които те не искат да бъдат. Разбира се, с нужните защити за най-незащитените – деца, жертви на престъпления и т.н. И обратно – за хората с публична власт пространството на лична защита следва да е силно ограничено до липсващо. Но никъде етичните стандарти не ни задължават да не поемаме рискове. В името на това обществото да знае.
Аз лично винаги ще избера разговор със свидетел на престъпление пред камера – с всички произтичащи от това етични дилеми – вместо журналистика по режисирано изтекли показания от МВР. Защото истинската журналистика се прави пред очите и от името на публиката. Другото е пиар.
Разликата между пиара и журналистиката се разбира, когато ти потрябва журналист. От вида честен и безпристрастен. От Червената книга на онези, пазили се да стоят между агитките, понасяйки удари от всички страни. Изпаднали в слаба позиция, добри и лоши, свои и чужди, либерали и консерватори пак се обединяват – този път в нуждата. И започват да викат почтената журналистика. Изненадани, бившите силни разбират, че за слабите журналистика няма. Ами няма – медиите са или ваши, или са срещу вас. Ти си го избра, както е казал мъдрецът.
Този смешен плач плакаха всички – от Цветан Цветанов, през Иван Гешев, до Ахмед Доган и Цветан Василев. Последният, участвал лично в процеса по придобиването на едни медии и обезшумяването на други в силните години на КТБ, днес пише в личния си сайт, че бил цензуриран от неетични журналисти или техните редактори. Нима?
Има нещо поучително в това как всички цензори намразват цензурата, упражнявана от някой друг, след като собствената им хунта ги избута отвъд разделението свой–чужд. Мило е, но не върши работа дори и за кратковременно злорадство.
През това време в TikTok и Instagram постжурналистиката експериментира и с нов бизнес модел: директна връзка с публиката чрез абонаменти, дарения и платформи за подкрепа. Не рекламодателят, а зрителят плаща.
От една страна, това би трябвало да е добре. Американският медиен критик Ей Джей Либлинг още през 1960 г. отбелязва: „Свободата на пресата е гарантирана за онези, които притежават преса.“

Но когато читателите и зрителите станат инвеститори, и то в среда, която от години е нормализирала нагласата да третира медиите като наемници на частен капитал, тогава и капиталисти на дребно могат да започнат да си искат своето. И ако не им харесва отражението в огледалото, да пожелаят да убият този, който го държи. Или поне да спрат да си плащат абонаментите.
А на пазара оцеляват идеи, стоки и услуги, от които някой има нужда. Икономистите му викали jobs-to-be-done теория. Хората „наемат“ продукт или услуга, за да им свършат определена работа. Ако се появи по-добър (евтин, лесен, забавен) начин да се свърши същата „работа“, старият продукт изчезва.
Доскоро журналистите малко елитарно и самонадеяно смятаха, че имат запазеното място на важни и нужни на обществото.
А може би вече не.
Няма да е първата професия, която е изчезнала поради отпаднала необходимост.
Съвсем не е невъзможно да си представим, че един ден и журналистиката ще се подреди в музея на професиите – до глашатая, телефонистката и словослагателя (този, който реди металните букви в печатарството). Заместена от създателите на новинарско съдържание за тези, които си плащат за споделеност и забавление.
Post Syndicated from Jin-Hee Lee original https://blog.cloudflare.com/account-abuse-protection/
Today, Cloudflare is introducing a new suite of fraud prevention capabilities designed to stop account abuse before it starts. We’ve spent years empowering Cloudflare customers to protect their applications from automated attacks, but the threat landscape has evolved. The industrialization of hybrid automated-and-human abuse presents a complex security challenge to website owners. Consider, for instance, a single account that’s accessed from New York, London, and San Francisco in the same five minutes. The core question in this case is not “Is this automated?” but rather “Is this authentic?”
Website owners need the tools to stop abuse on their website, no matter who it’s coming from.
During our Birthday Week in 2024, we gifted leaked credentials detection to all customers, including everyone on a Free plan. Since then, we’ve added account takeover detection IDs as part of our bot management solution to help identify bots attacking your login pages.
Now, we’re combining these powerful tools with new ones. Disposable email check and email risk help you enforce security preferences for users who sign up with throwaway email addresses, a common tactic for fake account creation and promotion abuse, or whose emails are deemed risky based on email patterns and infrastructure. We’re also thrilled to introduce Hashed User IDs — per-domain identifiers generated by cryptographically hashing usernames — that give customers better insight into suspicious account activity and greater ability to mitigate potentially fraudulent traffic, without compromising end user privacy.
The new capabilities we’re announcing today go beyond automation, identifying abusive behavior and risky identities among human users and bots. Account Abuse Protection is available in Early Access, and any Bot Management Enterprise customer can use these features at no additional cost for a limited period, until the general availability of Cloudflare Fraud Prevention later this year. If you want to learn more about this Early Access capability, sign up here.
The barrier to entry for fraudulent behavior is dangerously low, especially with the availability of massive datasets and access to automated tools that commit account fraud at scale. Website owners aren’t just dealing with individual hackers, but industrialized fraud. Last year, we highlighted how 41% of logins across our network use leaked credentials. This number has only grown following the exposure of a database holding 16 billion records, and multiple high-profile breaches have since come to light.
What’s more, users reuse passwords across multiple platforms, meaning a single leak from years ago can still unlock a high-value retail or even a bank account today. Our leaked credential check is a free feature that checks whether a password has been leaked in a known data breach of another service or application on the Internet. This is a privacy-preserving credential checking service that helps protect our users from compromised credentials, meaning Cloudflare performs these checks without accessing or storing plaintext end user passwords. Passwords are hashed — i.e., converted into a random string of characters using a cryptographic algorithm — for the purpose of comparing them against a database of leaked credentials. If you haven’t already turned on our leaked credential check, enable it now to keep your accounts safe from easy hacks!
Access to a large database of leaked credentials is only useful if an attacker can cycle through them quickly across many sites to identify which accounts are still vulnerable due to password reuse. In our Black Friday analysis in 2024, we observed that more than 60% of traffic to login pages across our network was automated. That’s a lot of bots trying to break in.
To help customers protect their login endpoints from constant bombardment, we added account takeover (ATO)-specific detections to highlight suspicious traffic patterns. This is part of our recent focus on per-customer detections, in which we provide behavioral anomaly detection unique to each bot management customer. Today, bot management customers can see and mitigate attempted ATO attacks in their login requests directly on the Security analytics dashboard.

In the card on the left within the Security analytics dashboard, you can view and address attempted account takeover attacks.
In the last week, our ATO detections combined caught an average of 6.9 billion suspicious login attempts daily, across our network. These ATO detections, along with the many other detection mechanisms in our bot management solution, create a layered defense against ATO and other malicious automated attacks.
To discern automation, or to discern intent and identity? That is the question. Our answer: yes and yes, as both are critical layers of a robust security posture. Attackers now operate at a scale previously reserved for enterprise services: they leverage massive credential leaks, use human-powered fraud farms to spoof devices and locations, and create synthetic identities to maintain thousands — even millions — of fake accounts for promotion and platform abuse. A human being with automated tools could be draining accounts, abusing promotions, committing payment fraud, or all of the above.
Beyond that, automation is accessible like never before, particularly as users become better acquainted with using AI agents and even long-standing, “traditional” browsers move toward having agentic capabilities by default. Whether it’s a lone actor using an AI agent or a coordinated fraud campaign, the threat isn’t as simple as a single script — it can involve human intent, with automated execution.
Consider the following scenarios we’ve heard from our customers:
We have 1,000 new users this month, but more than half of them are fake identities who benefit from a free trial, then disappear.
The attacker logged in with the correct password, so how do I know that it isn’t the real user?
This entity is acting at human pace, and they are draining accounts.
These problems can’t be solved by only assessing automation; they require checking for authenticity and integrity. This is the gap that our dedicated fraud prevention capabilities address.
Let’s start by assessing the earliest point of potential account abuse: account creation. Fake or bulk account creation is one of the biggest topics in conversations about website fraud, as it can open the door for attackers to access an application — or even an entire business model.
Cloudflare is giving customers the tools to assess suspicious account creation at the source in two ways:
Disposable email check: Detect when users sign up with disposable, or throwaway, email addresses commonly used for promotion abuse and fake account creation. These disposable email services allow attackers to spin up thousands of “unique” accounts without maintaining real infrastructure, particularly unauthenticated disposable emails that provide instant access without account creation or free unlimited email aliases. Customers can use this binary field as they build rules to enforce security preferences, choosing to block all disposable emails outright, or perhaps issuing a challenge to anyone attempting to create an account with a disposable email.

Email risk: Cloudflare analyzes email patterns and infrastructure to provide risk tiers (low, medium, high) that customers can use in security rules. We know that not all email addresses are created equal; an address with the format [email protected] carries different risk characteristics than [email protected]. Email risk tiers allow customers to express their tolerance for risk and friction at the point of account creation.
Both disposable email check and email risk are now available in security analytics and security rules, equipping website owners to protect their account creation flow. These detections address a fundamental problem: by the time an account is committing abuse, it’s already too late. The website owner has already paid acquisition costs, the fraudulent user has consumed promotional credits, and remediation requires manual review. Mitigating suspicious emails means adding the appropriate friction at signup — the moment it matters most.
Understanding patterns of abuse requires visibility: not only into the network, but of account activity. Traditionally, security has meant looking through the lens of IPs and isolated HTTP requests to spot automated activity, but website owners aren’t just thinking in terms of network signals; they are also considering their users and known accounts. That’s why we’re expanding our mitigation toolbox to match the way applications are actually structured, focusing on user-based detection of fraudulent activity.
Attackers can effortlessly rotate IPs to hide their tracks. But forcing them to repeatedly generate new, credible accounts introduces massive friction, especially when combined with account creation protections. When we look past the network layer and map fraudulent actions to a given compromised or abusive account, we can spot targeted behavior tied to a single, persistent actor and put a stop to the abuse. In this way, we’re shifting the defense strategy to the account level, instead of playing whack-a-mole with rotating IP addresses and residential proxies. This means that our customers can mitigate abusive behavior based on the way their applications separate identity.
To arm website owners with this capability, Cloudflare is releasing a Hashed User ID that customers can use in Security analytics, Security rules, and Managed Transforms. User IDs are per-domain, cryptographically hashed versions of the values in the username field, and each user ID is an encrypted, unique, and stable identifier generated for a given username on a customer application. Importantly, the actual username is not logged or stored by Cloudflare as part of this service. As with leaked credentials check and ATO detections, which identify login traffic and then encrypt credentials for comparison, we are prioritizing end user privacy while empowering our customers to take action against fraudulent behavior.
With access to Hashed User IDs, website owners can:
See top users: Which accounts have the most activity?
See when a unique user logs in from a country they usually don’t — or multiple countries in one day!
Mitigate traffic based on unique user, such as blocking a user with historically suspicious activity.
Combine fields to see when accounts are being targeted with leaked credentials.
See what network patterns or signals are associated with unique users.

The expanded view of a single Hashed User ID within the Security analytics dashboard, showing the activity details of that unique user, including their login location and their browser.
This user-level visibility transforms how website owners can investigate and mitigate traffic. Instead of examining individual requests in isolation, our customers can see the full picture of how attackers are targeting and hiding among legitimate users.
If you want to learn more about this Early Access capability, sign up here. All Bot Management Enterprise customers are eligible to add these new Account Abuse Protection features today, and we’d love to open the conversation with any and all prospective Bot Management customers.
While bot detections will continue to answer the question of automation and intent, fraud detections delve into the question of authenticity. Together, they give website owners comprehensive tools to fight against the full spectrum of account abuse. This suite is one step in our ongoing investment to protect the entire user journey — from account creation and login to secure checkouts and the integrity of every interaction.