AWS Shield Advanced is embracing the AWS WAF Anti-DDoS managed rule group: What changes and how to prepare

2026-07-27 Eitav Arditti

Post Syndicated from Eitav Arditti original https://aws.amazon.com/blogs/security/aws-shield-advanced-is-embracing-the-aws-waf-anti-ddos-managed-rule-group-what-changes-and-how-to-prepare/

Application-layer distributed denial of service (DDoS) attacks are difficult to detect because they closely resemble legitimate traffic. HTTP request floods are now among the most common vectors targeting web applications, using valid-looking requests that blend in with normal user activity.

In June 2025, AWS launched the AWS WAF Anti-DDoS managed rule group, built specifically for application-layer (L7) DDoS protection. AWS Shield Advanced is adopting it as the default application-layer protection, and in time as the only one. On July 27, AWS Shield Advanced begins adding the Anti-DDoS managed rule group to eligible web access control lists (ACLs) in Count mode. It will not cause any interruption to your traffic alongside your existing L7 automatic mitigation and WAF rules. In this blog post, we provide details regarding the Anti-DDoS managed rule group and when the change is expected to reach your web ACLs. You will understand the phases and steps that you need to take before the finish date, including how the monitoring and metrics will change.

Anti-DDoS managed rule group features

The Anti-DDoS managed rule group builds on what Shield Advanced automatic mitigation already provides. It profiles your traffic, learns what normal traffic looks like for your application, and establishes a baseline in minutes rather than hours. When an attack starts, it reacts within seconds and there are no health checks to configure. The rule group adds a Challenge action to the Block and Count actions you already use. Challenge decisions are driven by the AMR labels that mark the suspicion level of each inspected request. One option is a silent browser challenge, which has a background verification that runs in the visitor’s browser with no interstitial page, so legitimate users are never interrupted while automated traffic is filtered out. You can also exclude workload paths that don’t support Challenge, which fall back to Block mitigations instead. Sensitivity is configurable to Low, Medium, or High, and you set it separately for Block and Challenge. Block and Challenge are tuned independently; meaning you can run Challenge at high sensitivity to catch more suspicious traffic while keeping Block low to avoid dropping legitimate requests or reverse it for a stricter posture.

The rest is about cost and visibility:

It uses less capacity than before. The rule group needs 50 web ACL capacity units (WCUs), down from the 150 the previous protection required, providing you with capacity for the rest of your rules.
The dashboard ships in the AWS Management Console for AWS WAF. It’s there now, showing live DDoS events, match metrics, and the top URIs, geographies, and IP addresses driving traffic.
It labels everything it inspects. Requests get labels for event-detected, graduated suspicion levels, and specific rules. Match on those labels in your own AWS WAF rules when you need logic the rule group doesn’t cover.
You don’t pay for the attack traffic. During active mitigation, blocked DDoS requests drop out of your monthly count. That exclusion covers AWS WAF request fees, Anti-DDoS managed rule group request fees, and Shield Advanced request charges.

AWS Shield Advanced isn’t required to use any of these features. Shield Advanced subscribers get the rule group included with AWS WAF and any customer can turn it on independently. See AWS WAF pricing for more information on costs.

Implementation details

Shield Advanced upgrades application-layer DDoS protection in five phases. The following dates are when AWS will act automatically, not the earliest date when you can act. After the rule group is deployed in Count mode on July 27, 2026, you can begin migrating right away rather than waiting for the October auto-upgrade. There’s no window where protection lapses. Your current automatic mitigation stays active through every phase until the Anti-DDoS managed rule group takes over. That handoff happens in a single operation, with no cutover window and no gap for your traffic flows.

Phase 1: Anti-DDoS managed rule group deployed in Count mode (rolling out July 27–August 7, 2026)

AWS adds the Anti-DDoS managed rule group in Count mode to every web ACL eligible for this rollout. Eligible means any Shield Advanced web ACL with at least one resource using application-layer automatic mitigation that isn’t already running the Anti-DDoS rule group. This is a broader set than the web ACLs eligible for the October auto-upgrade (Phase 3), which applies a stricter test. The deployment rolls out gradually, starting July 27 and expected to finish by August 7, 2026, so different web ACLs might be updated on different days. There’s no impact to your traffic because the rule group watches and labels requests without acting on them while your existing automatic mitigation keeps running. Throughout the evaluation period, you receive DDoS events, metrics, and AWS WAF labels at no additional charge.

Phase 2: Free evaluation period (July 27–September 30, 2026)

The existing automatic mitigation and the Anti-DDoS managed rule group run side by side each detecting independently. Automatic mitigation continues to protect your resources while the rule group operates in Count mode. To compare their detection results, use the DDoSAttackRequests metric, AWS WAF labels, and the Anti-DDoS dashboard. All Anti-DDoS managed rule group charges are waived during this period, including the subscription fee, per-request fees, and WCU consumption costs for the eligible web ACLs from phase 1.

Phase 3: Auto-upgrade begins (October 1, 2026)

For eligible web ACLs, the auto-upgrade mirrors your existing automatic mitigation configuration. The rule group inherits your current setting, so a Block configuration comes up in Block mode and a Count configuration comes up in Count mode in a single, atomic operation. The rule group takes over in the same step that disables automatic mitigation, so protection never drops for an instant. This is a handoff rather than a cutover with no window where your resources are unprotected. If you’d rather not upgrade you can opt out by contacting AWS Support before the auto-upgrade date.

Phase 4: Guided migration (available July 27–December 31, 2026)

You don’t have to wait for the October auto-upgrade to migrate. As soon as the rule group is deployed in Count mode between July 27 and August 7, 2026, you can move to it on your own schedule. This is the path to use for web ACLs that aren’t eligible for the Phase 3 auto-upgrade, meaning mixed-mode web ACLs or ones with resources that don’t have automatic mitigation enabled. Work with your AWS account team and AWS Support at any point in this window to plan and complete the migration. Eligible web ACLs are also upgraded automatically starting October 1 (Phase 3), so guided migration is mainly for the web ACLs the auto-upgrade can’t cover.

Phase 5: Shield Advanced application-layer automatic mitigation sunset (January 1, 2027)

As of January 1, 2027, the Shield Advanced application-layer automatic mitigation feature will no longer be available. Resources that haven’t migrated to the Anti-DDoS managed rule group will lose automatic application-layer DDoS mitigation.

Capability	Shield Advanced application layer automatic mitigation	Anti-DDoS managed rule group (AWSManagedRulesAntiDDoSRuleSet)
Feature type	Shield Advanced automatic mitigation	AWS WAF managed rule group
Detection and mitigation speed	Requires a baseline period; mitigation varies per event	Enhanced detection and faster mitigation
Configuration scope	Per resource (Shield API)	Per web ACL (AWS WAF API)
Mitigation actions	Count, Block	Count, Block, and Challenge
Sensitivity controls	None	Low, Medium, and High for both Block and Challenge
Non-HTML path handling	N/A	URI regex exemptions for Challenge
WCU consumption	150 WCUs	50 WCUs
Health checks	Required (Amazon Route 53 health-based detection)	Not required, provides automatic traffic profiling
Availability	Shield Advanced only	AWS WAF and Shield Advanced (see pricing)

Observability

The existing automatic mitigation and the Anti-DDoS managed rule group use separate Amazon CloudWatch namespaces and metric structures. The rule group gives you three tiers of observability: tier 1 tells you an attack is happening, tier 2 shows which requests it flagged and why, and tier 3 shows what it did about them. You don’t need all three on day 1 because most customer teams start at tier 1 to confirm detection is working, then add the others as they tune.

Tier 1: Event detection alarms

You can detect DDoS events using two CloudWatch metrics, each with its own namespace.

	DDoSDetected (Shield)	DDoSAttackRequests (Anti-DDoS managed rule group)
Namespace	AWS/DDoSProtection	AWS/WAFV2
Requires Shield Advanced	Yes	No
Scope	L3, L4, and L7 events	L7 events only
Value during event	Binary (0 or 1)	Count of requests observed
Value outside event	Reported once daily (keeps metric alive)	Absent (no data points)
Dimensions	ResourceArn	Resource, ResourceType

What this means for your existing alarms:

After the application-layer automatic mitigation feature is sunset, DDoSDetected still fires for infrastructure layer 3 and layer 4 events, so your existing network layer and transport layer alarms remain valid. For the full list, see AWS Shield Advanced metrics.
DDoSAttackRequests is the Anti-DDoS managed rule group equivalent for application-layer event detection. Alarm on Sum >= 1 to detect any event, or set a volume threshold (for example, more than 10,000 requests per minute) for severity-based alerting.
During the evaluation period, both metrics fire independently and you can validate detection parity before migrating your application-layer alarms.
Because DDoSAttackRequests is absent when there are no active DDoS events, set treat-missing-data to missing or notBreaching for alarms on this metric.

Tier 2: Detection labels for custom monitoring

Every request the Anti-DDoS managed rule group evaluates gets a label. Where tier 1 tells you an attack started, tier 2 shows which requests looked suspicious and how confident the rule group was. The labels surface as AWS WAF metrics in the AWS/WAFV2 namespace: AllowedRequests, BlockedRequests, and CountRuleMatch. Each carries the LabelName and LabelNamespace dimensions under the awswaf:managed:aws:anti-ddos: namespace.

event-detected – Requests observed during a detected DDoS event
ddos-request – Requests identified as part of the attack
low-suspicion-ddos-request, medium-suspicion-ddos-request, high-suspicion-ddos-request – Graduated suspicion levels
challengeable-request – Requests eligible for browser challenge

Chart suspicion-level trends on a CloudWatch dashboard to see how an attack builds. Match on the labels in your own AWS WAF rules or dig into them in your AWS WAF logs with CloudWatch Logs Insights or Amazon Athena when you need to understand a specific event after the fact.

Tier 3: Mitigation action metrics

Where tier 2 shows what the rule group flagged, tier 3 shows what it did about those requests during an event. You’ll find these metrics as ChallengeRequests, BlockedRequests, and CountRuleMatch, each scoped by the rule label that produced it.

ChallengeAllDuringEvent – Requests challenged during an active event
ChallengeDDoSRequests – Suspected DDoS requests challenged based on suspicion level
DDoSRequests – Requests blocked (or counted in Count mode)

Watch these during a live event to see whether mitigation is keeping up. If you’re challenging far more requests than you’re blocking, your configuration might be too cautious, and you can raise the sensitivity level after you trust the numbers.

Observability summary

Tier	Automatic mitigation	Anti-DDoS managed rule group
Event alarm	DDoSDetected in AWS/DDoSProtection (binary, L3/L4/L7)	DDoSAttackRequests in AWS/WAFV2 (request count, L7)
Detection labels	None	event-detected, ddos-request, suspicion levels, challengeable-request
Mitigation actions	Not visible (Shield-managed rule group metrics not exposed)	ChallengeAllDuringEvent, ChallengeDDoSRequests, DDoSRequests
Dashboard	Shield console event history	Shield console and Anti-DDoS dashboard in the AWS WAF console
Historical analysis	Shield event history only	AWS WAF logs (CloudWatch Logs, Amazon Simple Storage Service (Amazon S3), Amazon Data Firehose)

Billing

Your Shield Advanced subscription includes the Anti-DDoS managed rule group for up to 50 billion requests per month, counted across your whole organization at the payer account level. For most customers that ceiling is well above normal traffic, so you won’t see a line item here unless you’re operating at very high volume. For the exact rates, see AWS WAF pricing and Shield Advanced pricing.

You aren’t charged for DDoS traffic while the Anti-DDoS managed rule group is actively mitigating, which means Block or Challenge mode rather than Count. This applies to AWS WAF request fees, Anti-DDoS managed rule group request fees, and Shield Advanced request charges. Leaving the rule group in Count mode past the evaluation period costs you the protection without the billing relief, so avoid staying in Count mode longer than you need to validate.

During the evaluation period (July 27 to September 30, 2026), the eligible web ACLs AWS auto-enrolled don’t incur per-request fees or WCU consumption, even when configured in Count mode.

The Anti-DDoS managed rule group works at the web ACL level, so every resource you associate with a web ACL shares that coverage. Before assuming a single resource accounts for the whole cost, look at how many resources sit behind each web ACL. A web ACL fronting 20 resources bills differently from one fronting 2, so check that count first and familiarize yourself with the workload protected by each web ACL.

Adding the Anti-DDoS managed rule group to a web ACL yourself isn’t part of the upgrade path, so standard pricing applies from the moment you enable it. The same is true for any resource that was already running the rule group before the rollout. To get the free evaluation, let the automatic rollout reach your web ACLs rather than adding the rule group ahead of it. There’s no penalty for adding it yourself; you just don’t receive the waiver on that web ACL.

Update your infrastructure as code

If you manage web ACLs with AWS CloudFormation, AWS Cloud Development Kit (AWS CDK), Terraform, or other infrastructure as code (IaC), the auto-upgrade changes your infrastructure configuration outside your templates. Your code is still the source of truth, so you need to do two things. First, change where the protection is declared. Today you enable application-layer automatic mitigation through the Shield API (EnableApplicationLayerAutomaticResponse), configured per protected resource. The Anti-DDoS managed rule group is configured through the AWS WAF API instead (CreateWebACL and UpdateWebACL), as a managed rule group statement inside the web ACL, scoped per web ACL rather than per resource. In IaC terms, you remove the Shield automatic-response block (for example, Terraform’s aws_shield_application_layer_automatic_response) and add the WAF managed rule group statement shown in the following section. Second, pull the upgraded web ACL back into your tooling before your next deploy, or your pipeline will try to revert the change.

For the full statement in Terraform, CloudFormation, and the AWS CDK, plus how to sync state after the auto-upgrade (terraform plan, CloudFormation drift detection, cdk diff), see the iac-webacl-examples helper.

Update your AWS Firewall Manager policy

If you run a Shield Advanced policy in AWS Firewall Manager today, that policy is what enabled application-layer automatic mitigation across your accounts. To keep that protection, add the Anti-DDoS managed rule group to an AWS WAF Firewall Manager policy. Your Shield Advanced policy still handles L3 and L4, while the application-layer piece moves to the AWS WAF policy. The migration is straightforward: add or reuse an AWS WAF Firewall Manager policy, put the Anti-DDoS managed rule group in it, and scope it to the same accounts and resources your Shield Advanced policy covers.

You can’t add the rule group from the Shield console or by editing an account-level web ACL directly, because Firewall Manager owns the web ACLs it creates and overwrites local edits. Instead, add the rule group to the AWS WAF policy and Firewall Manager pushes it to every in-scope account.

You can make this change in the console or as code. If you manage your Firewall Manager policies as code, don’t edit them in the console: add a new AWS WAF policy or update an existing one in your templates with the Anti-DDoS managed rule group included, and deploy it using the following Firewall Manager policies using IaC steps. Otherwise, use the console.

In the console, follow Creating an AWS Firewall Manager policy for AWS WAF to create the policy and reach the Edit policy rules page. Add the Anti-DDoS rule group, listed there as AWS AntiDDoS Protection for Layer 7 attacks (AWSManagedRulesAntiDDoSRuleSet), as a new rule group under First rule groups so it evaluates before your other managed groups, but below any Allow custom rules you use to fast-path known-good traffic.

If you protect CloudFront distributions, make this change in your Global policy, and repeat it in each AWS Regional policy for regional resources. Save the policy, and Firewall Manager rolls the change out to in-scope accounts, which can take a few minutes.

After being added, the rule group appears as the first rule group in the policy, as shown in the following screenshot:

Figure 1: AntiDDoS enabled

Firewall Manager policies using IaC

If you manage Firewall Manager policies as code, make the change in your template instead of the console. The Anti-DDoS managed rule group goes into the AWS WAF policy’s ManagedServiceData, a WAFV2 policy definition carried as a JSON string, added to the first rule groups so it evaluates early. For the ManagedServiceData JSON with CloudFormation, Terraform, and AWS CDK examples, see the firewall-manager-examples helper.

Whichever path you take, scope the policy to the same accounts and resources your Shield Advanced policy already covers, so no resource loses application-layer protection during the move.

Getting started

Between July 27 and August 7, 2026, AWS will add the Anti-DDoS managed rule group in Count mode to Shield Advanced web ACLs that have resources using application layer automatic mitigation but not yet the Anti-DDoS rule group. After it reaches your web ACL, you can evaluate it, and migrate whenever you’re ready, without waiting for the October auto-upgrade.

Review the Anti-DDoS dashboard in the AWS WAF console. The dashboard shows real-time DDoS events, match metrics, and top traffic sources.
Compare event detection side by side. During Count mode, both systems detect independently. Check the DDoSDetected metric in AWS/DDoSProtection alongside DDoSAttackRequests in AWS/WAFV2 to validate detection parity for your resources. You can deploy the CloudWatch comparison dashboard from the AWS Samples repository to view both systems on a single dashboard.
Explore AWS WAF labels. Enable AWS WAF logging and query for labels in the awswaf:managed:aws:anti-ddos: namespace. Look at suspicion levels (low-suspicion-ddos-request, medium-suspicion-ddos-request, high-suspicion-ddos-request), event-detected, and challengeable-request to see per-request visibility into detected events.
Start with Low sensitivity for Block actions during evaluation to minimize false positive risk. Tune up as you gain confidence from the Anti-DDoS dashboard and AWS WAF label data.
Plan your configuration. Review sensitivity levels, URI exemptions for non-HTML paths, and web ACL priority placement. The Anti-DDoS managed rule group should run at the highest priority in your web ACL, or right below any custom rules with the Allow action.
Sync your IaC templates. After the auto-upgrade adds the Anti-DDoS managed rule group to your web ACL, fetch the current state into your IaC tooling (Terraform refresh, CloudFormation drift detection, AWS CDK import) before your next deployment.

Conclusion

The Anti-DDoS managed rule group profiles your traffic within minutes and mitigates within seconds, where the automatic mitigation it builds on established its baseline over hours, and it gives you granular visibility into what it’s doing. The evaluation period exists so you can watch both systems run on your own traffic before anything changes. Spend the first few weeks in Count mode confirming the new detection matches what you see today, then move your alarms over and pick a sensitivity level you’re comfortable with. If you run a web ACL across several resources, or you manage rules through AWS Firewall Manager, contact AWS Support before you start so you don’t have to unwind anything later. The Shield Advanced application-layer automatic mitigation feature retires on January 1, 2027, and anything still relying on it needs to be migrated by then.

Resources

If you have feedback about this post, submit comments in the
Comments section below.

[$] Hazard pointers for the kernel

2026-07-27 corbet

Post Syndicated from corbet original https://lwn.net/Articles/1084015/

The kernel’s read-copy-update (RCU) subsystem ensures that data will not be
deleted until it is known that there are no threads holding references to
it. RCU works well and is widely used throughout the kernel, but it can
increase memory use and add significant delays before unused kernel objects
are cleaned up. Hazard pointers are
an alternative approach to lockless data updates that offers better
performance, for some situations at least. The kernel community is
currently considering a
hazard-pointer implementation by Mathieu Desnoyers and Paul McKenney.

Announcing the Cloud Security Alliance on AWS Compliance Guide

2026-07-27 Juan Rodriguez

Post Syndicated from Juan Rodriguez original https://aws.amazon.com/blogs/security/announcing-the-cloud-security-alliance-on-aws-compliance-guide/

AWS Security Assurance Services is announcing the release of the Cloud Security Alliance (CSA) Compliance Guide on Amazon Web Service (AWS), a new resource that maps the 17 control domains and 207 control objectives of the Cloud Controls Matrix v4.1 (CCM) to AWS services and recommended implementation practices. The guide is intended to help organizations using AWS plan, implement, and evidence the controls relevant to their CCM scope, including those pursuing or maintaining CSA STAR certification.

What is the Cloud Controls Matrix?

The Cloud Security Alliance is a not-for-profit organization dedicated to defining and raising awareness of best practices for cloud security. AWS maintains CSA STAR Level 2 certification, which couples the requirements of ISO/IEC 27001:2022 with the CCM. The CSA STAR documentation and the AWS Consensus Assessments Initiative Questionnaire (CAIQ) are available to AWS customers through AWS Artifact.

The CSA Cloud Controls Matrix is a cybersecurity controls framework developed by the CSA that provides a detailed set of security controls mapped across multiple domains (such as audit and assurance, identity and access management, and encryption and key management) specifically designed to assess and manage security risks in cloud computing environments. The CCM is cloud agnostic, designed to be applicable to any cloud service provider or deployment model, such as infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS), regardless of the underlying technology or vendor, providing universal security controls that organizations can apply across cloud platforms.

Responsibility models

CCM defines its own Shared Security Responsibility Model (SSRM) with three categories: Cloud service provider (CSP)-owned, customer-owned, and shared (independent or dependent). The guide recommends using the SSRM together with the AWS Shared Responsibility Model. For controls that AWS owns, the guide points to AWS attestations available through AWS Artifact (for example, SOC reports, ISO certificates, and the CSA STAR attestation) as inherited evidence. For controls that customers own or share, the guide describes how to implement and evidence them using AWS services. Using a CSA STAR–certified AWS service doesn’t by itself make a customer workload compliant. Customers remain responsible for configuring services, managing access, protecting data, and implementing additional controls based on their environment, risk assessments, and regulatory obligations. The guide is informational and doesn’t replace the AWS compliance documentation and certifications available through AWS Artifact.

What’s inside the guide

For each control, the guide states applicability, describes how organizations can implement the control on AWS, identifies common pitfalls, and lists examples that can be used as evidence during an assessment.

Related resources

Download available: Here

For further assistance, contact AWS Security Assurance Services. If you have feedback about this post, submit comments in the Comments section below.

Building a scalable personalized recommendation system on AWS: From batch to real-time

2026-07-27 Shraddha Anil Naik

Post Syndicated from Shraddha Anil Naik original https://aws.amazon.com/blogs/big-data/building-a-scalable-personalized-recommendation-system-on-aws-from-batch-to-real-time/

Amazon.com receives millions of visits every day, and behind every product recommendation on our website is a system that needs to process customer signals, run machine learning (ML) models, and deliver results before the next visit. Doing this across global marketplaces for millions of customers at tens of thousands of requests per second, while keeping experimentation fast and infrastructure costs bounded, is an orchestration challenge as much as a machine learning one.

Our team built a system that addresses this challenge. This post shows how we did it using a batch-first architecture with AWS Lake Formation, Amazon Managed Workflows for Apache Airflow (Amazon MWAA), Amazon Athena, AWS Glue, Amazon SageMaker, and Amazon DynamoDB, and how we later extended it with Amazon MemoryDB for real-time vector similarity search when we needed to incorporate more real-time signals.

Architecture overview

Data flow from the Lake Formation data lake and Athena through Airflow-orchestrated pipelines using Glue and SageMaker into DynamoDB for batch serving and MemoryDB for real-time inference

Data flows from the centralized data lake (Lake Formation and Athena) through Airflow-orchestrated pipelines using Glue for processing and SageMaker for ML workloads, into DynamoDB for batch serving and MemoryDB for real-time inference

The data lake foundation: Centralized access with Lake Formation

Every recommendation pipeline starts with data. We built a centralized data lake to create a single source of truth that any pipeline or consumer can access without duplicating data or building bespoke extract, transform, and load (ETL) pipelines.

Golden datasets: Shared once, used everywhere

Before the data lake, each recommendation pipeline independently extracted and transformed its own copy of product catalog, transaction history, and embeddings. This led to subtle inconsistencies: one pipeline might use a slightly different join logic or a stale snapshot, making it difficult to compare model performance or debug discrepancies across pipelines.

Now, we publish curated, validated datasets once, and every consumer (Airflow DAGs, ML notebooks, analytics dashboards) reads from the same tables through the same governed access. This means:

New pipelines start faster. A new recommendation model does not need its own data extraction logic. It queries the existing golden datasets from day one.
Consistency across models. When we compare model A to model B, we know both models are trained and inferred on the same underlying data.
Cross-team collaboration. Multiple teams share the same tables as a single source of truth.
Two-way data flow. The data lake serves as both source and destination. Our pipelines read golden datasets as inputs and write computed outputs (model scores, feature sets, intermediate results) back to the lake, where they become inputs for other pipelines. This creates a compounding effect: each new pipeline enriches the lake for the next one.

Why Lake Formation?

Our data is stored in Amazon Simple Storage Service (Amazon S3), partitioned by marketplace. Our data consumers (Airflow pipelines, ML notebooks, analytics tools) live in separate AWS accounts from the data producers. We chose AWS Lake Formation because it adds governance on top of S3 without requiring data migration:

Fine-grained cross-account access. Grant table-level permissions per consumer role, without managing bucket policies manually.
Schema governance through AWS Glue Data Catalog. Scheduled Glue crawlers infer schemas from files in S3, keeping the catalog current as data evolves.
Multi-Region consistency. We deploy identical infrastructure across multiple AWS Regions using AWS Cloud Development Kit (AWS CDK), each Region serving its local marketplaces.

Orchestration: Amazon Managed Workflows for Apache Airflow (Amazon MWAA)

We chose Amazon Managed Workflows for Apache Airflow (Amazon MWAA) as our orchestration layer. MWAA removes the operational burden of managing Airflow infrastructure: automatic scaling of workers, built-in high availability, and managed upgrades mean our team focuses on pipeline logic rather than cluster maintenance. MWAA lets us define complex multi-step workflows with rich dependencies in Python code, and its operator model lets us encapsulate team-specific conventions into reusable building blocks.

Each recommendation pipeline follows a consistent pattern:

The consistent recommendation pipeline pattern moving from data extraction through model training, batch inference, vector search, ranking, and publishing

We built a library of reusable custom Airflow operators, each encapsulating one of our core compute engines. This reduced new pipeline development from weeks to days in our team’s experience.

Athena and AWS Glue: Data access and processing

Amazon Athena is how our pipelines read from Lake Formation. Our custom operator runs SQL queries against the Glue Data Catalog and automatically runs UNLOAD to write results to S3: serverless, no infrastructure to manage, and integrated with the Lake Formation permission model.

AWS Glue handles compute-intensive data transformations through PySpark: joining datasets, filtering, deduplication, aggregation, and formatting ML outputs into final recommendation lists. We configure Glue with Auto Scaling worker pools (for example, 2–50 workers of G.8X type) so jobs scale with data volume per marketplace. All jobs run ephemerally: they read from S3, write to S3, and require no long-running clusters.

Amazon SageMaker: Training, inference, and vector search

Amazon SageMaker powers the ML-intensive stages of our pipelines across three workload types, all orchestrated as steps within our Airflow DAGs:

Training

We use SageMaker Training Jobs to train our recommendation models on GPU instances (for example, ml.g5). Training data is prepared by upstream Glue jobs and staged in S3. Our custom Airflow operator submits the training job, monitors its progress, and registers the resulting model artifact in S3. Once training completes, the artifact is immediately available for batch inference or endpoint deployment within the same DAG run. This means a single DAG can go from raw data to trained model to deployed inference without manual handoffs, and we can retrain it on fresh data every pipeline cycle with zero operator intervention.

Batch inference

SageMaker Batch Transform runs our trained models at scale, generating the outputs that feed into downstream ranking and publishing steps. Our batch inference operator handles job submission, polls for completion, and writes the output location to the DAG’s S3 convention so the next Glue step can pick it up automatically. Batch Transform lets us run inference without provisioning persistent infrastructure, and we can scale instance count and type independently for every pipeline based on data volume.

Vector search

Generating recommendations for millions of customers requires searching across hundreds of thousands of candidate products per customer. Exact search at this scale is prohibitively expensive, so we use approximate nearest neighbor (ANN) search using FAISS to find similar products efficiently, run as SageMaker Processing Jobs.

The workflow:

Build a FAISS index over the candidate catalog.
Query the index with per-customer vectors to find top-K nearest neighbors.
Return ranked candidate lists per customer.

We distribute query vectors across the SageMaker Processing fleet using S3-based sharding (ShardedByS3Key). Each instance receives the full candidate index but only a fraction of the query vectors. Every instance builds an identical FAISS index, searches its shard of queries, and writes results to S3. The downstream Glue step merges all shards into the final recommendation lists. This lets us scale horizontally by adding instances without changing any code.

Why SageMaker inside MWAA?

Running SageMaker jobs as MWAA tasks (rather than standalone) gives us:

End-to-end lineage. Every model training run, inference job, and vector search is tracked as part of a DAG execution. We can trace a recommendation in DynamoDB back to the exact training run, data snapshot, and ANN search that produced it.
Retry and failure handling. If a SageMaker job fails (spot instance preemption, transient capacity errors), Airflow retries it automatically with backoff. No manual re-runs.
Resource sequencing. Training must finish before inference, inference before ANN search. The Airflow dependency model handles this naturally without polling scripts or step function state machines.
Unified monitoring. One Airflow dashboard shows the health of all pipelines: Glue ETL, SageMaker training, SageMaker inference, and DynamoDB publishing. No context-switching between consoles.

Putting it together: A complete pipeline example

Our recommendation generation pipeline illustrates the full flow:

The complete recommendation generation pipeline: data lake extraction, model training, batch inference, vector search, merge and rank with Glue, and publishing to DynamoDB

Note that the operators shown (GlueSQLOperator, VectorSearchOperator, and others) are custom internal operators built on top of the Airflow AWS provider, not open-source libraries. Here is a simplified version of what this looks like in code:

from airflow import DAG
from airflow.models.baseoperator import chain
from airflow.utils.task_group import TaskGroup

dag = DAG("recommendation_generator", schedule="0 18 * * 4")  # Weekly
task_groups = []

for marketplace in [...]:  # global marketplaces
    with TaskGroup(group_id=marketplace, dag=dag) as group:

        # Step 1: Extract data from lake
        candidates = GlueSQLOperator(
            task_id="select_candidates",
            tables=[f"{marketplace}.catalog", f"{marketplace}.products"],
            sql="select_candidates.sql", dag=dag)

        customer_history = GlueSQLOperator(
            task_id="select_customer_history",
            tables=[f"{marketplace}.transactions"],
            sql="select_customer_vectors.sql", dag=dag)

        customers = AthenaSQLOperator(
            task_id="select_customers", database=marketplace,
            query="select_customer_cohort.sql", dag=dag)

        # Step 2: Train model
        train = ModelTrainingOperator(
            task_id="train_model",
            training_input={"task_id": customer_history.task_id},
            instance_type="ml.g5", dag=dag)

        # Step 3: Batch inference
        inference = BatchInferenceOperator(
            task_id="batch_inference",
            model={"task_id": train.task_id},
            input_data={"task_id": candidates.task_id}, dag=dag)

        # Step 4: Vector search via SageMaker Processing Job
        ann_search = VectorSearchOperator(
            task_id="ann_search",
            index_input={"task_id": inference.task_id},
            query_input={"task_id": customer_history.task_id},
            k=60, instance_count=10, dag=dag)

        # Step 5: Merge and rank with Glue
        merge_and_rank = GlueSparkOperator(
            task_id="merge_and_rank",
            script="merge_results.py", dag=dag)

        # Step 6: Publish to DynamoDB
        publish = DynamoDBPublishOperator(
            task_id="publish_recommendations",
            table_name="Recommendations", dag=dag)

        # Task dependencies
        [candidates, customer_history] >> train >> inference
        [inference, customers] >> ann_search >> merge_and_rank >> publish

    task_groups.append(group)

chain(*task_groups)  # Execute marketplaces sequentially

Key patterns in this DAG

Marketplace isolation. Each marketplace runs in its own TaskGroup. A failure in one does not block the others.
Parallel data extraction. Independent Athena/Glue queries run concurrently before converging at the training step.
Sequential marketplace execution. chain() runs marketplaces one at a time to avoid resource contention across large SageMaker and Glue jobs.
Reusable operators. We built custom operators like GlueSQLOperator, VectorSearchOperator, and DynamoDBPublishOperator that encode our team’s conventions (cross-account access, S3 staging, retry logic, metrics) into shared building blocks. New pipelines are mostly configuration rather than infrastructure code, and these operators are shared across dozens of pipelines.
Implicit data passing. Each operator writes its output to a convention-based S3 path and downstream operators automatically resolve the upstream output location. No hard-coded paths between steps.

This pattern powers hundreds of pipelines across global marketplaces, with each marketplace as an isolated TaskGroup in the DAG.

Serving layer: DynamoDB + ECS

Our Java-based Amazon Elastic Container Service (Amazon ECS) service reads pre-computed recommendations from Amazon DynamoDB at request time:

Receive request with customer ID, marketplace, customer context, and page context.
Read pre-computed recommendations from DynamoDB.
Apply real-time filters (availability, eligibility constraints).
Re-rank based on real-time context signals.
Return the response.

Amazon DynamoDB is designed to provide single-digit millisecond reads at our scale and time-to-live (TTL) for automatic cleanup of stale recommendations.

Extending to real-time

In recommendation system terms, our batch pipeline handles the retrieval stage offline. Although this covers the majority of our traffic, we identified scenarios where weekly freshness was not enough to capture what customers are doing right now. The real-time extension adds an online retrieval and ranking path for signals that cannot wait for the next batch cycle.

To address these, we extended our system with Amazon MemoryDB (which now supports Valkey as its open-source engine) for real-time vector similarity search and SageMaker real-time endpoints for on-demand embedding generation. The same Airflow pipelines that publish to DynamoDB also publish product vectors to MemoryDB (through our MemoryDB publish operator), and the same model in our batch pipeline is deployed to a SageMaker endpoint for single-item inference at request time.

At serving time, when we want to incorporate fresh signals, the service calls the SageMaker endpoint to generate an embedding on the fly, then queries MemoryDB for the nearest neighbors. These fresh signals include recent search queries, cart additions, and other in-session activity that changes faster than our weekly batch cycle. In our workloads, this gives us sub-millisecond vector search latency without re-running the full batch pipeline. Critically, the batch pipeline keeps the MemoryDB product index fresh. Our Airflow DAG includes a MemoryDB publish operator that refreshes the full product vector index weekly, so real-time queries always search against an up-to-date index.

Batch and real-time are not competing approaches: batch handles slow-moving signals (purchase history, catalog relationships) while real-time handles fast-moving ones (current session, new arrivals, trending items). Both paths share the same models, the same data lake, and the same serving service.

For a detailed deep-dive on this real-time architecture, see Real-time personalized recommendations with Amazon SageMaker and Amazon Managed Valkey.

Security and access control

Security is a foundational concern for a system that spans multiple AWS accounts, processes customer behavioral data, and runs across multiple AWS Regions.

Cross-account access: Lake Formation grants are issued to consumer-account AWS Identity and Access Management (IAM) roles, ensuring consumers can query tables without direct S3 bucket access. Each consumer role receives only the permissions it needs for its specific tables.

IAM execution roles: Each compute engine (MWAA, Glue, SageMaker) runs under a dedicated least-privilege IAM role.

Network isolation: MWAA environments and the ECS serving layer are deployed within virtual private clouds (VPCs), with separate VPC configurations per Region.

Reliability and failure handling

Regional isolation: Each AWS Region runs an independent copy of the system. DynamoDB tables are regional, each populated by the local batch pipeline. MemoryDB clusters are regional, with the product vector index refreshed by the local Airflow DAG. This means a regional failure or pipeline delay in one Region does not affect other Regions.

Batch pipeline failures: If a pipeline fails mid-run, the previous DynamoDB data remains live and continues serving recommendations until the next successful run. Airflow retries failed tasks automatically with configurable backoff. TTL on DynamoDB records bounds how long stale data persists. Failed pipeline runs trigger automated alerting so the on-call engineer can investigate.

Real-time path resilience: MemoryDB is deployed in a multi-AZ configuration with automatic failover. The real-time path is an extension of the batch system, and batch recommendations from DynamoDB remain available regardless of real-time path availability.

Lessons learned

Start batch, add real-time incrementally. Batch pipelines are easier to debug, cheaper to operate, and sufficient for most recommendation scenarios. Add real-time path only when you have clear indication that specific customer signals (for example, in-session activity, search queries) need sub-hour freshness to remain relevant.
Match the serving path to signal velocity. Not every signal needs real-time processing. Categorize your signals by how quickly they change, and route accordingly: batch for slow signals, real-time for fast ones, re-ranking for in-between.
Freshness does not always require re-computation. A batch-generated candidate set remains largely valid between runs. What changes is relative relevance. Re-ranking at serving time with recent customer activity gives the impression of real-time without the cost of real-time candidate generation.
A centralized data lake accelerates everything. Golden datasets eliminated weeks of per-pipeline data extraction work, made model comparisons trustworthy, and let new team members ship their first pipeline in days instead of weeks. The upfront investment in Lake Formation governance paid for itself within the first quarter.
Invest in reusable operators. Custom Airflow operators encapsulating Athena/Glue/SageMaker patterns let teams ship new pipelines in days. The operators encode best practices (retry logic, cross-account access, metrics) so pipeline authors can focus on business logic.
Separate compute from storage. S3 as the universal intermediate layer + ephemeral Glue/SageMaker jobs means you pay only for active computation. No idle clusters between weekly pipeline runs.

Conclusion

We built this system because every customer interaction is an opportunity to surface the right product at the right time. Serving tens of thousands of requests per second across millions of customers in global marketplaces, our batch-first architecture uses AWS Lake Formation for governed data access, Amazon MWAA for orchestration, Amazon Athena for data lake queries, AWS Glue for distributed processing, Amazon SageMaker for training, inference, and vector search, and Amazon DynamoDB for low-latency serving. When we needed to incorporate more real-time signals, we added Amazon MemoryDB vector search paired with SageMaker real-time endpoints for on-demand embedding generation, extending into real-time without replacing the batch foundation.

The architecture choices we have made, batch for efficiency and real-time for freshness, all serve the goal of helping customers discover what they need faster. If you are building personalized experiences at scale, we hope these patterns give you a useful starting point.

This would not have been possible without the Everyday Essentials engineering team, whose collective effort turned these ideas into a production system serving customers every day. We are also grateful for the support and guidance from Sam Heyworth, Nirav Desai, and Ankur Datta, and the broader Everyday Essentials leadership team.

About the authors

ASRock Rack 4U16X-GNR2 NVIDIA HGX B300 8-GPU Server Review

2026-07-27 Patrick Kennedy

Post Syndicated from Patrick Kennedy original https://www.servethehome.com/asrock-rack-4u16x-gnr2-nvidia-hgx-b300-8-gpu-server-intel-zutacore-review/

We review the ASRock Rack 4U16X-GNR2, an 8x NVIDIA HGX B300 server with enormous network bandwidth and two liquid-cooling options

The post ASRock Rack 4U16X-GNR2 NVIDIA HGX B300 8-GPU Server Review appeared first on ServeTheHome.

Buc-ee’s #lastweektonight

2026-07-27 LastWeekTonight

Post Syndicated from LastWeekTonight original https://www.youtube.com/shorts/J6OzxDLdnZ0

S9 E16: Supreme Court Overturns Roe & Water: Last Week Tonight with John Oliver

2026-07-27 LastWeekTonight

Post Syndicated from LastWeekTonight original https://www.youtube.com/watch?v=74lpwDODypc

GNU Binutils 2.47 released

2026-07-27 jzb

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

Version
2.47 of GNU
Binutils has been released. In addition to the usual bug fixes
there are some notable new features in this release including added
support for a number of RISC-V standard extensions, a command-line
option (-M annotate) which displays the symbol for
undefined instructions for AArch64, and more. The 32-bit s390 target
has been deprecated with this release.

Zigbee Disappointment: It’s NOT Zigbee’s Fault! #shorts

2026-07-27 BeardedTinker

Post Syndicated from BeardedTinker original https://www.youtube.com/shorts/0NjQDGALWgw

This $39 Radio Tracks You Off-Grid

2026-07-27 Crosstalk Solutions

Post Syndicated from Crosstalk Solutions original https://www.youtube.com/shorts/PyFO46rP3pg

AWS Weekly Roundup: Local Zone in Athens, Claude Opus 5 on AWS, Lambda durable execution for .NET, and more (July 27, 2026)

2026-07-27 Daniel Abib

Post Syndicated from Daniel Abib original https://aws.amazon.com/blogs/aws/aws-weekly-roundup-july-27-2026/

Last week I had the privilege of spending three days in São Paulo with technical builders from across Latin America, brought together for a regional tech event full of deep-dive sessions, hands-on workshops, and conversations with customers and partners. What struck me most wasn’t any single session, it was the energy of a technical community that so rarely gets to be in the same room. People traded architecture ideas over coffee, sketched out solutions on whiteboards, and left with a longer list of things to try than they arrived with. It’s a good reminder that, for all the tooling we build, the community around it is what makes the technology stick.

That community spirit connects nicely to the week’s biggest infrastructure news, which is all about bringing AWS closer to where builders actually are.

Now, let’s get into this week’s AWS news…

Headlines
AWS Local Zone in Athens, Greece: AWS has opened a new Local Zone in Athens, Greece, the second Local Zone in EMEA with support for Amazon S3 and Amazon EBS Local Snapshots, so you can store and process data within Greece to help meet local data residency requirements. The Athens Local Zone supports Amazon EC2 (C7i, M7i, and R7i instances), Amazon S3 with the One Zone-Infrequent Access storage class, Amazon EBS, and Amazon ECS.

Athens, Greece skyline

AWS Local Zones place AWS infrastructure much closer to large population and industry hubs, enabling applications that require single-digit millisecond latency, such as real-time gaming, media production, and financial services, to run where end users actually are. For builders in Greece, you can now run latency-sensitive workloads locally while connecting seamlessly to the nearest AWS Region for services that don’t require low latency, giving you the flexibility to architect hybrid, latency-optimized applications without managing your own data center infrastructure. To learn more, visit AWS Global Infrastructure and Sustainability Blog post.

Last week’s launches
Here are some launches and updates from this past week that caught my attention:

Claude Opus 5 on AWS: You can use Anthropic’s Claude Opus 5, the most advanced Opus model yet, matching Claude Fable 5’s top-tier intelligence in many domains at Opus-tier pricing. Amazon Bedrock offers Claude Opus 5 with zero data retention (ZDR) enabled by default, giving you Opus’ top-tier intelligence while meeting your data governance requirements unlike Claude Fable 5. You have two ways to access Claude Opus 5: Amazon Bedrock and Claude Platform on AWS. To learn more, visit the deep dive blog post.
AWS Lambda durable execution SDK for .NET is now generally available: You can now build resilient, long-running workflows in C# using Lambda durable functions, without implementing custom progress tracking or integrating an external orchestration service. The SDK is a natural fit for multi-step applications like payment processing pipelines, AI agent orchestration, and human-in-the-loop approvals, it checkpoints progress automatically and can pause execution for up to a year. If you’re a .NET developer building serverless workflows, this removes a lot of the plumbing you used to write by hand.
Amazon Bedrock AgentCore now delivers unified observability with traces and logs in a single log group: Amazon Bedrock AgentCore now delivers agent traces and prompts to the same Amazon CloudWatch log group as your agent’s logs. Previously, telemetry was split across destinations, trace spans went to a shared log group while prompts, inputs, and outputs went to a separate one, so debugging a single agent invocation meant searching in multiple places. You can now debug an invocation in one place, and apply fine-grained access control and customer-managed key (CMK) encryption at the individual agent level.
Amazon Connect delivers more natural agentic voice experiences: Amazon Connect now supports more natural, human-sounding agentic voice experiences across 50+ languages, including Portuguese, Spanish, French, Italian, Japanese, Korean, and Thai, with over 100 new voice options and conversational improvements that make AI interactions sound more fluid. Connect’s agentic self-service lets AI agents understand, reason, and take action across voice and digital channels, adapting to a customer’s tone and sentiment. You can now build contact center experiences that feel natural to callers in far more of the languages your customers actually speak.
Amazon SageMaker Unified Studio now supports Amazon OpenSearch: You can now query and analyze your search and log analytics data from Amazon OpenSearch directly alongside other data assets in Amazon SageMaker Unified Studio. With this connection, you can combine operational search data in OpenSearch with data from sources like Amazon Redshift, Amazon S3, and relational databases, all within a single, governed environment. It’s especially useful when you need to correlate analytical and operational workloads, such as joining application logs with transactional data to uncover insights.
Amazon CloudWatch announces coding agent insights: Amazon CloudWatch now gives engineering leaders visibility into how AI coding tools are driving value across their organization. Coding agent insights integrates with the Claude apps gateway for AWS to collect telemetry from Claude Code without additional instrumentation, and also supports agents like Codex and GitHub Copilot. As teams scale AI coding adoption, you can now measure the return on that investment with metrics built on OpenTelemetry, no custom instrumentation required.

For a full list of AWS announcements, be sure to keep an eye on the What’s New with AWS page.

Other AWS news
Here are some additional posts and resources that you might find interesting:

Evaluating AI Agents: A production blueprint with Strands and AgentCore: A practical guide to evaluating AI agents before and after they reach production, using Strands Agents and Amazon Bedrock AgentCore. If you’re moving agents from prototype to production, this post is a great companion to the AgentCore observability update above, it walks through how to measure agent quality systematically rather than by gut feel.
Building multi-region resiliency for AWS CloudFormation custom resource deployment: Learn how to architect CloudFormation custom resources for multi-region resiliency, so your infrastructure-as-code deployments stay reliable even when a single Region has issues.
Introducing Amazon Simple Email Service (SES) pricing plans: Amazon SES now offers pricing plans that give you more predictable costs as your email volume grows. If you send at scale, this could simplify your billing significantly.

Upcoming AWS events
Check your calendar and sign up for upcoming AWS events:

AWS Summits: AWS Summits are free events that bring the cloud and AI community together to connect, learn, and explore the latest technologies. Browse the full calendar to find a Summit near you in the second half of 2026.
AWS Community Days: Community-led conferences where content is planned, sourced, and delivered by community leaders. If you’re in Latin America, don’t miss AWS Community Day Belo Horizonte on August 22, registration is open at awscommunityday.com.br.

Join the AWS Builder Center to connect with builders, share solutions, and access content that supports your development. Browse here for upcoming AWS-led in-person and virtual events and developer-focused events.

That’s all for this week. Check back next Monday for another Weekly Roundup!

This post is part of our Weekly Roundup series. Check back each week for a quick roundup of interesting news and announcements from AWS!

Security updates for Monday

2026-07-27 jzb

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

Security updates have been issued by Debian (chromium, hplip, and linux-6.1), Fedora (firefox, GitPython, google-osconfig-agent, lego, libgit2, libreswan, libwebsockets, moby-engine, p11-kit, pam, python-idna, rust-libgit2-sys, skopeo, systemd, trafficserver, webkitgtk, and xrdp), Mageia (giflib, graphite2, libnfs, vorbis-tools, wget, and yelp), Red Hat (firefox, thunderbird, and webkit2gtk3), and SUSE (amazon-ecs-init, chromedriver, ffmpeg-7, ffmpeg-8, firefox, google-osconfig-agent, gpg2, java-17-openjdk, java-25-openjdk, kernel, libsrt1_5, nginx, perl-HTTP-Date, perl-XML-Bare, proftpd, python-pyasn1, python-soupsieve, python313-astropy, python313-urwid, systemd, thunderbird, and trivy).

We’re open sourcing our privacy proxy CLI

2026-07-27 Hannah Wang

Post Syndicated from Hannah Wang original https://blog.cloudflare.com/open-sourcing-our-privacy-proxy-cli/

Debugging privacy-preserving protocols is hard. Oblivious HTTP has several different steps across four different parties, not to mention binary HTTP encoding and details spread across many draft RFCs. We've taken what we've learned operating protocols like Oblivious HTTP at the scale of millions of requests per second, and wrapped it up in a nice, clean CLI tool — that we are open sourcing today.

We call it our privacy-client, or pvcli. We’re releasing it under the Apache-2.0 License, and it is open for contributions.

Here’s a single line of code that executes a full Oblivious HTTP request with a relay, gateway and origin. Don't worry if you don't know what that means, we'll cover it below.

We’ll explain why we built this tool, and show just how handy it can be.

Why privacy protocols can be hard to debug

Let’s take a closer look at our motivation for creating pvcli. Over time, the Privacy team’s product suite and customer base grew. We added products like Privacy Proxy and Privacy Gateway, which power Apple’s Private Relay, Microsoft’s Edge Secure Network VPN, Flo Health’s Anonymous Mode, and more. With it came an increasing amount of special customer requirements, domain knowledge, and complexity. As a result, we saw increased friction in development and incident response.

To see this in action, let’s look at how one of our products implements Oblivious HTTP, also known as OHTTP. First, a quick primer. OHTTP provides users with a privacy guarantee: no one can know both who made a request and what they’re requesting. To achieve this, OHTTP requires two servers, a relay and a gateway, operated by two non-colluding parties.

Below is a sequence diagram of OHTTP, where our customer owns the relay and Cloudflare owns the gateway. At a high level, OHTTP can be broken down into these steps:

Client gets public key from the gateway.
Client encrypts the request and sends it to the relay.
Relay removes “who” the client is from the encrypted request, and sends it to the gateway.
Gateway decrypts the request, and sends it to the target.
Target processes the request, and sends a response to the gateway.
Gateway encrypts the response, and sends it to the relay.
Relay sends the encrypted response to the client.
Client decrypts, and gets the plaintext response.

It involves quite a bit of back-and-forth, as you can see:

Each step is a potential point of failure that we have to consider while debugging!

In particular, we saw certain kinds of problems when debugging OHTTP.

Customers asked for ways to test the live system from their end, and we often wrote one-off, custom clients for our customers specific deployments.
Figuring out which step caused an issue was time-consuming. Was the root cause a bug in our system or our customer’s system?
Examining raw bits was tedious and highly prone to human error. OHTTP builds on binary HTTP, which is a binary encoded HTTP request. Anytime we needed to check the binary encoding, we were painstakingly going through raw bits.

As a result, we decided to place all of our privacy protocols in one tool. It has a clean interface that’s already familiar, displays every single step of the protocol in order, and is flexible enough to support new protocols and architectures.

To see the difference this makes, let’s see an OHTTP debugging scenario — before and after pvcli.

Debugging without pvcli

Say we operate an OHTTP relay that sits in front of a customer's gateway. The customer has asked us to do an end-to-end test with a request:

Recall the OHTTP steps from earlier. The first step is to fetch the public key from the gateway. We use curl to fetch it from the customer gateway and get this back:

That’s a big binary string in hex. To make sense of it, we look at OHTTP RFC 9458 §3 and parse it manually:

0029 is 41 in decimal, telling us this public key entry has 41 bytes associated with it.
55 is the public key ID.
0020 identifies the asymmetric encryption method we can use. In this case, DHKEM(X25519, HKDF-SHA256).
b9bb667e2230dc01c6d6cc047f94a1083beb185c63e50ec09f7692a5a0832540 is the public key.
0004 tells us there are 4 bytes of symmetric cryptographic IDs that follow.
0001 and 0001 identify the symmetric encryption methods we can use: HKDF-SHA256 and AES-128-GCM.

We repeat this process for however many public keys are in the binary string.

Next, we convert our original HTTP request into binary HTTP, referencing RFC 9292. We manually craft the binary with the help of some bespoke scripts:

We verify each field:

02 means it's an indeterminate-length request
04504f5354 is POST
056874747073 is https
117461726765742e6f687474702e696e666f is target.ohttp.info
and so on

Finally, we form a wrapper HTTP request that will hold our OHTTP request. To do so, we spend some more time writing another makeshift script that encrypts the binary HTTP request in the manner OHTTP specifies, using the public key from earlier. We create a header, which is the concatenation of public key ID, asymmetric encryption method ID, and symmetric encryption method IDs. Then, we concatenate header and encrypted binary HTTP request, resulting in:

We put those bytes into the body of our wrapper HTTP request, and send it to our relay. We get back a response.

What does that mean? We reach out to the customer to ask if they can share logs from their gateway. In the meantime, we double-check the bits we've crafted. The decoded public keys look fine. The binary HTTP request… Oh! We see:

BHTTP is length prefixed. That means we specify a length (0x0a is 10 in decimal), and then 10 bytes follow. But here, 11 bytes follow. There is an extra 20 before the 00. 20 represents a space character, so we must have accidentally added that when building the body. We remove the extra character, resend, and it works!

Debugging with pvcli

With pvcli, all of that is now a single command:

It handles all the binary parsing and encrypting for us, and prints logs in case we want to dive deeper:

What used to be a fragile process — involving manipulating bits, gluing together scripts, and referencing long RFCs — is now one command.

What pvcli can do

To install:

pvcli takes a lot of inspiration from curl. We designed it with the “principle of least surprise” in mind. As a result, a lot of the arguments are the same as curl’s! Try a quick GET request to our cdn-cgi endpoint:

If you’re curious about what is happening under the hood, you can use -v to get detailed logs:

Now, about that OHTTP command from earlier: you use –ohttp to tell pvcli to construct an OHTTP request. You pass in the relay as the –first-hop and the gateway as the –proxy. The target will be an echo server, so you can see what the target would see. In this command, we filled in the arguments with a relay, gateway, and target from ohttp.info.

Try running the command yourself!

We’ve encountered many cases where we wanted to pass headers to the relay, rather than the target. You are able to do that with --first-hop-header:

Similarly, we’ve also had cases where we wanted to authenticate to the relay with mTLS, to ensure that the correct client is talking with the correct relay. To do that, you can use –first-hop-client and --first-hop-key.

And it just works. Need to test a full Oblivious HTTP request with a relay, a gateway, arbitrary headers, and mTLS? Or perhaps only request through a gateway? Or maybe you just want to see the OHTTP key configuration? pvcli can do it with a single command, debugging included.

Why build our own tool?

There are some great tools for OHTTP that already exist. Martin Thomson’s Rust implementation and Chris Wood’s Go implementation were incredibly helpful when we built out our original OHTTP implementation a few years ago. But pvcli is not only focused on OHTTP. We’re looking to add as many privacy-preserving protocols as we can to the tool. So while there are other OSS tools out there for debugging OHTTP, nothing combines OHTTP, CONNECT proxying, MASQUE and Privacy Pass (coming soon) all in one place.

Contribute to pvcli

Oblivious HTTP is an amazing protocol, and we would love to see you use it. We hope that this tool helps people debug OHTTP and write their own OHTTP implementations.

We are accepting contributions! To get started, clone the repo at https://github.com/cloudflareresearch/pvcli, and submit a pull request.

If you're looking for ways to contribute, here are some things on our to-do list. For MASQUE, we plan to add support for proxying TCP over HTTP/3, and UDP and/or IP over HTTP/2 and HTTP/3. For OHTTP, we plan to support post-quantum cryptography, add timing/latency information, support Chunked OHTTP, and improve logging.

The Power of Pre-Internet Nostalgia

2026-07-27 The Atlantic

Post Syndicated from The Atlantic original https://www.youtube.com/watch?v=ehUZwaqZfio

Shark Chaser: A WWII Story

2026-07-27 The History Guy: History Deserves to Be Remembered

Post Syndicated from The History Guy: History Deserves to Be Remembered original https://www.youtube.com/watch?v=JmrA0-EZ2uk

Съдия Мирослава Тодорова: Ние сме отговорни за всичко, което си спестяваме

2026-07-27 Роси Михова

Post Syndicated from Роси Михова original https://www.toest.bg/sudiya-miroslava-todorova-nie-sme-otgovorni-za-vsichko-koeto-si-spestyavame/

Въпросите задават Грегъри Сток и Роси Михова

Съдия Мирослава Тодорова: Ние сме отговорни за всичко, което си спестяваме

През вече далечната 1987 година американският биофизик Грегъри Сток преживява нещо като Големия взрив. Той публикува своята „Книга на въпросите“ (The Book of Questions) и неочаквано за самия него тя светкавично се превръща в световен бестселър. Нейната популярност се разширява до неподозирани мащаби и я задържа цели 60 седмици в класацията на най-четените книги на The New York Times. Това е времето, когато в Белия дом и Кремъл са Рейгън и Горбачов, Берлинската стена и Световният търговски център си стоят непокътнати, един приличен мобилен телефон тежи около килограм, а дигиталните фотоапарати, интернетът и разчитането на човешкия геном са само работни проекти в главите на мечтатели.

С една дума, всичко е различно. Но и всичко е същото. Хората се борят с парични и семейни проблеми, с любовта, загубата, изкушението и страха. Познават предателството. Търсят смисъл и удовлетворение.

Затова и въпросите от тази книга, публикувана преди 40 години, са същите умоблъсканици, които ни стряскат и днес. На нейните страници авторът описва изцяло измислени, дори абсурдни ситуации, като всяка от тях ни поставя пред някаква хипотетична дилема. От нас се очаква да направим избор, който неизбежно е свързан с морален компромис. Така скритият въпрос, който всеки път задава Сток, всъщност е един: каква цена сме склонни да платим за желанията и убежденията си?

Подобни дилеми, но съвсем не хипотетични, се решават ежедневно на едно обширно бойно поле – това на правото. Битката, поне на теория, винаги е за доброто и справедливостта. Но доброто само по себе си също е вид компромис – то е онзи фин баланс между възмездие и милост, наказание и опрощение, закон и право.

Точно затова се изкушихме да поканим за разговор по въпросите на Грегъри Сток не друг, а съдия Мирослава Тодорова*.

Да започнем с нещо леко: ако можехте да придобиете способност или качество, за което се възхищавате на някой друг, какво бихте избрала?

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

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

Ако имахте кристално кълбо, в което да видите истината само за едно от следните три неща – Вас самата, живота или бъдещето, то какво бихте искала да узнаете и защо?

Бих избрала истината за бъдещето. Аз съм любопитна и ми се струва, че по природа съм изследовател. Искам да разбера какво ще произтече от настоящия момент. Например какво ще се случи с човешкия мозък? Какви ще са поколенията, които ще са изцяло формирани в дигитална среда и ще задоволяват голяма част от потребностите си виртуално? Дали все още ще умеят да пишат ръкописно? Какъв ще бъде човекът и неговият свят? Доколко изкуственият интелект ще премахне необходимостта от физическа намеса на човека? Дали това ще направи хората прекалено лениви? Ще носят ли те отговорност за дължимите усилия, които си спестяват? Защото в крайна сметка ние сме отговорни за всичко, което си спестяваме.

И ако полето, в което има роля човекът, се стеснява, то как ще предефинираме самото понятие за общност? Как ще контролираме нарастващия риск от безотговорно поведение и злоупотреба с ИИ? Как ще управляваме риска от предоверяване в технологии, които предлагат да ни заместят във вземането на решения? Предизвикателствата пред човечеството ще са вече от съвсем друг порядък. И аз искам да знам какви ще са последиците от нашите действия и бездействия сега. И как и дали хората ще се справят.

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

Имам много ценни за мен неща и всички те са свързани с любимото ми убежище – изкуството. Струва ми се обаче, че няма да взема нищо. Може би това показва, че съм някакъв отчаян персонаж, но мисля, че всичко, което ми е истински важно, е вече в главата ми. Огънят не може да ми го отнеме.

Макар че това може би не е най-честният отговор. Навярно, без да се усетя дори, ще тръгна с мобилния си телефон, защото той така или иначе е навсякъде с мен. А в паметта му се съхраняват много неща – дори детските снимки на майка ми.

Бихте ли се съгласила да станете по-непривлекателна физически, но в замяна на това да бъдете значително по-интелигентна?

Не. Не бих искала нито да съм по-грозна в полза на интелигентността, нито да съм по-глупава, но по-красива. Самата амбиция да бъдем такива, каквито не сме, ми е чужда. Не бих казала, че тя ме отблъсква, когато я наблюдавам у другите, но провокира у мен известно съчувствие. Защото е симптом на някакъв болезнен вътрешен дефицит и усещане за несигурност. Това, разбира се, не означава, че моето самочувствие е от железобетон, но поне въпросът за класациите и за това как се съотнасям по разни показатели спрямо останалите, не ме занимава.

Аз мисля, че едно от големите изпитания и големите лични постижения на човека е да постигне хармоничен баланс между това, което автентично мисли и изпитва, и начина, по който го изразява чрез външния си вид. По отношение на външността ние правим с годините това – рисуваме автопортрета си.

Бихте ли убила невинно животно със собствените си ръце, ако това е единственият начин да се нахраните?

Ще ми се да кажа: не. Обаче в това би имало доза лицемерие, при положение че приемам някой друг да убива вместо мен, а аз да купувам разфасовките с месо в магазина. Освен това не съм сигурна, че в определена ситуация аз самата няма да го направя. Имам предвид, че си давам сметка за тъмната страна, която всеки от нас носи.

Нали си спомняте онази потресаваща сцена в „Огледало“ на Тарковски, когато майката преодолява градската си изтънченост, губи невинността си и сама обезглавява петела, за да нахрани децата си? Никога няма да забравя онази нейна горчиво победоносна, дори макабрена полуусмивка накрая. И онази мрачна решителност, с която обръща очи към камерата и към всеки от нас.

Така че изпитанията на съдбата, а също и нашата тъмна страна могат да ни поставят в ситуация, в която собствената ни атавистична сила за съпротива и оцеляване ще ни изненада.

В обичаен неделен ден десетки хиляди души посещават Лувъра. Представете си, че терорист заплаши да унищожи или всички посетители на музея, или всичките му колекции. Вие трябва да решите кое от двете да спасите. Кое бихте избрала?

Това за мен е проклет въпрос. Защото аз наистина обичам изкуството. Конкретно в Лувъра имам поне няколко любими неща, за които ще страдам много, ако бъдат погубени. Но няма нищо по-важно от хората. Ще спася хората.

Тук ще вляза в ролята на адвокат на дявола и ще защитавам обратната теза, за да внеса елемент на спор в иначе хармоничния ни разговор. Индивидуалният живот е преходен. Всички посетители така или иначе след няколко десетилетия ще умрат. Но загубата на събраното в Лувъра би било в известен смисъл „лоботомия“ на човешката култура, и то за сметка на бъдещите поколения. Ако смъртта на хората е биологично неизбежна трагедия, то смъртта на изкуството не е ли цивилизационна катастрофа?

Цивилизационна катастрофа е загубата на памет. Но да, незавидна ще бъде участта на оцелелите, които ще трябва да изградят мост към бъдещето. Те ще трябва да измислят как да разкажат на децата и внуците за това, което е изгубено безвъзвратно. При всички положения обаче не бих се колебала – изкуството се създава за хората, независимо какво мислим и говорим за стремежа на творците да постигнат абсолютното. Надчовешки или извънчовешки ценности и радости не съществуват.

Като стана дума за паметта, амнезията бива два вида: при едната губите паметта си за минали събития, а при другата вече не можете да формирате нови спомени. Ако паднете лошо и трябва да страдате от едното или другото, кое би било по-страшно?

Имам аргументи в полза и на двата възможни отговора. От една страна, човек интуитивно се хваща за миналото – за съкровените неща, които е преживял и които формират неговата идентичност. Ние сме сума от нашите преживявания и загубата на памет за тях е вид психологическа смърт. А има и друго – всеки от нас е изгубил близки на сърцето му хора. И е вярно това клише, че те са живи, докато в нас е жив споменът за тях. Да се откажем от спомените си означава да ги изоставим и в известен смисъл – да ги умъртвим завинаги.

И все пак аз споделям идеята, че най-високата възможност да бъдем себе си се свежда до това да сме добри хора. А добрият човек е възможен само ако приеме несигурността и неопределеността на това, което идва… ако не издига стени около себе си и успява да събере кураж да живее открито, тоест незащитено. С ясното съзнание, че го чакат разочарования, наранявания и дори разрушение. Противното обаче – защитната отбрана или пък просто живот на безопасна дистанция от другите – води до загуба на същинските човешки достойнства: доверие, чувствителност, мекота, крехкост. Ако загубиш тях, ако бягаш непрекъснато от всяка потенциална болка, ти се превръщаш в призрак, който броди единствено из крепостните стени на най-голямото си поражение. Изборът да се живее в миналото е някакъв такъв тип самозащита.

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

Представете си, че можете да предотвратите само едно от следните три събития: земетресение в Чили, което би убило 40 000 души; самолетна катастрофа на софийското летище, която би погубила 200 души; или автомобилна катастрофа, в която би загинал най-близкият Ви приятел. Кое бихте избрали?

Това е почти като избора на Софи от филма на Алън Пакула, който по същество е абсолютно непоносим и нерешим. Знаете, там на входа на концлагера искат от майката на две малки деца да избере кое от тях да живее, защото, ако не избере, ще умрат и двете. Софи прави саморазрушителен, но в същото време съвсем рационален избор да предпочете детето, което има по-големи шансове да оцелее – защото е по-голямото дете, защото е русо момче и защото говори немски. Но дали това е разумен, макар и жесток компромис, или е най-големият родителски грях?

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

И все пак правим уговорката, че тук говорим за живота на много близки хора, на най-скъпи на сърцето същества. Ако не е така, този въпрос няма отговор. Не може да е вярно решение, в което избираме да пожертваме един човешки живот, за да спасим друг или милион други. Бройката няма значение. Всеки човек е носител на вътрешноприсъщата стойност на човешкото достойнство. А това значи – и на правото за автономно управление на собствената съдба. От Просвещението насам ние сме се съгласили, че човекът винаги е цел и е недопустимо да бъде използван като средство в преследване на други цели. Това означава, че не можем да претегляме относителната тежест на един човешки живот срещу тази на друг. Иначе казано, няма значение дали човекът е болен, стар или несимпатичен. Защитата на всеки човешки живот е еднаква.

Ако можехте да прекарате една година в пълно щастие, но след това да не помните нищо от преживяното, бихте ли го направила?

Нямам съмнение, че бих го направила. Може би това идва пак от нагласата ми на изследовател. Бих искала да знам какво наричат абсолютно щастие, как се преживява, как и дали би ме променило, дори след това да не помня нищо.

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

А аз го преживявам по друг начин. Да, би било жалко да не помня нищо и да не мога после да го споделя и разкажа. Но от друга страна, смятам, че ако има тази възможност, човек задължително трябва да се възползва от нея и да се гмурне в радостта. Защото щастието е това – способност да преживяваш радост. А радостта не е просто смях и веселие. Радостта е сериозно нещо.

Имам няколко въпроса, които не са от книгата на Грегъри Сток, но са също донякъде „проклети“. Ако научите, че преди повече от век вашият прапрадядо е обрал и убил някого, трябва ли днес да компенсирате неговите вече далечни потомци?

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

На хората, чиято семейна история злощастно се е оплела преди век с моята, бих се опитала да помогна. Но ще го направя не като задължение на потомка на престъпник, а като човек, който е научил за тяхната болка или нужда и има възможност да направи нещо сега.

Но ако окрупним този въпрос и го разгледаме като обществен казус: трябва ли да носим отговорност за нещо – било то робство, геноцид или друга историческа несправедливост, с което нямаме никаква връзка, освен че сме от същата религия, националност или етнос като извършителите? Къде свършва индивидуалната отговорност и започва колективната вина?

Аз вярвам в силата и значението на контекста. Ние носим отговорност за себе си, за това, което сме тук и сега. Неуместно е да се опитваме със съвременния аршин да прекрояваме миналото и да проектираме върху него разбиранията си за добро и зло. Няма как да съдим хора, които преди векове са били просветители и основатели на университети, за това, че са били и робовладелци, a не либерални демократи. Не можем да оценяваме Средновековието например с критериите на модерността, нито пък да наслагваме върху настоящето моралните щампи на миналото.

Изобщо идеята, че можем да се превръщаме в съдии на всичко – на миналото, на прародителите си, на интимни отношения, в които държавата дори няма място, на мен ми се вижда също толкова разрушителна, както и опасността от тоталитарен режим. Това са опасности от един и същ порядък.

Бихте ли подкрепила закон, който позволява на жертвите на престъпление сами да избират наказанието за извършителя, вместо това да се решава от държавата?

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

А целта на правосъдието е да помогне на хората да продължат да живеят заедно дори след невъобразимо тежък разрив в техните отношения. Пострадалите имат нужда от разкриване на истината за това какво се е случило, от рехабилитация, от сигурност и подкрепа, от ясен знак, че се отнасяме с разбиране и уважение към страданието им, за да могат да преработят травмата и да намерят сили да продължат нататък. Превръщането им в централни обвинители или палачи води само до задълбочаване на тази травма, а понякога – и до човешки разпад.

Същевременно човекът, извършил престъпление, ще се поправи само ако му бъде оставен достоен изход и ако се отнасяме с доверие към способността му оттук нататък да води порядъчен живот. Достойнството е последното убежище на обречения на наказание и е добре всеки колега съдия по наказателни дела да приеме осъзнато това положение.

И накрая – ако трябваше да татуирате на ръката си послание към себе си, какво би било то?

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

Ако обаче говорим за послание към себе си в смисъл на окуражаване и подкрепа, то се сещам за един стих на Рилке, от който често имам нужда:

Кой говори за победа? Да устоим, това е всичко.
(Wer spricht von Siegen? Überstehn ist alles.)

* Мирослава Тодорова е наказателен съдия в Софийския градски съд и бивш председател на Съюза на съдиите в България. Тя е известна със своята непримиримост към политическата намеса и зависимостите в съдебната система, както и с отстояването на основните граждански права като кауза в полза на държавността. През годините съдия Тодорова плаща висока цена за своите професионални позиции: уволнена е от Висшия съдебен съвет, а след като съдът я възстановява, отново е наказана. Впоследствие Европейският съд по правата на човека в Страсбург постановява по заведеното от нея дело, че е нарушено правото ѝ на свободно изразяване на мнение.

Cognyte Sells a Mobile Cell Surveillance Van

2026-07-27 Bruce Schneier

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/07/cognyte-sells-a-mobile-cell-surveillance-van.html

Yet another Israeli mass surveillance company:

Made by Israeli surveillance company Cognyte, the tech simulates a mobile phone tower, which forces nearby phones to connect to it. That enables cops to keep tabs on any phones in the vicinity whether they’re owned by a suspect in a case or not. Cognyte’s contract with the state of Texas reveals that the simulator, called FalcoNet, can be concealed within the vehicles, hidden in a backpack for on-foot missions or attached to a helicopter. It’s the same technology as the infamous Stingray, one of the original cell-site simulators made by defense giant L3Harris.

Can a Progressive Win a Purple State?

2026-07-27 The Atlantic

Post Syndicated from The Atlantic original https://www.youtube.com/watch?v=mMu9wnMdq8s

Шансът на един варненски брутализъм

2026-07-27 Веселин Златков

Post Syndicated from Веселин Златков original https://www.toest.bg/shansut-na-edin-varnenski-brutalizum/

Шансът на един варненски брутализъм

След като в последните месеци написах няколко текста, пълни с горчиви и песимистични констатации за родния ми град, сега реших да напиша нещо оптимистично и положително за Варна. А това, да ви призная, никак не е лесно…

Новите проблеми на Варна

Варна като разказ за пропуснат шанс и за системно разминаване между амбиция и реалност. В града се строи повече, отколкото се живее, обещава се повече, отколкото се изпълнява. Между морето, имотите и провалените проекти наднича въпросът „Къде потъна потенциалът?“. От Веселин Златков.

Скандалът с „незаконния град“ Баба Алино за момента леко е затихнал, но големите драми там тепърва предстоят, когато започнат делата и някой тръгне реално да събаря нещо повече от оградата. Междувременно се появяват нови сигнали за имотни и строителни далавери, но десант на министри заради тях не се очаква, защото едва ли ще донесат политическия ефект, който се търси на първо място.

Семейната фирма на кмета Благомир Коцев ще трябва да плати близо 200 000 евро на държавата, защото е ползвала без правно основание две поляни в Морската градина. Решението беше окончателно потвърдено от Върховния касационен съд. Коцев обаче реши да гледа положително на нещата и заяви, че това само доказвало, че прословутите беседки около семейния ресторант „Хоризонт“, заради които тръгна делото, са законни. Кметът обаче няма как да отрече, че той е ръководил бизнеса в периода, за който фирмата е глобена, преди да се качи на политическата сцена първо като областен управител, после като кмет. А това поставя неудобния въпрос за разделението между кмета Коцев и бизнесмена Коцев – въпрос, който просто няма как да получи някакъв позитивен отговор.

Баба Алино: Светеца, мъченикът и украинецът

Скандалът около Баба Алино постави много въпроси. Най-интересният обаче не е кой е строил (защото вече е ясно, че за „най-голямото беззаконие“ доказателства няма), а защо точно сега всички решиха да забележат. Един варненски поглед към случая – от Веселин Златков.

В Общинския съвет боричкането между фракциите стигна до такова ниво, че две седмици преди Деня на Варна – 15 август, големият концерт за празника е пред провал. Така че варненци може и да не видят съгражданката си Дара да пее на най-голямата сцена точно в годината на нейния тотален триумф. Е, то няма да сме варненци, ако не си причиним сами нещо такова.

На всичко отгоре напоследък се заговори за „забавяне“ на пазара на недвижими имоти – биещото сърце на градската икономика – и това създава сериозна тревога. А новият туристически сезон тръгна зле и не е ясно дали това ще се компенсира до края на лятото, което както винаги ще се изниже неусетно и по-бързо от очакваното.

Но! Когато търси, човек намира положителното и оптимистичното дори в цялата тази каша.

Добрата новина за Варна, която открих, е свързана с една мистериозна сграда в центъра на града, буквално на метри от Общината. Тя е опасана с висока ограда, през която трудно ще надникнеш, защото е подсилена с ламарина. В двора ѝ сега има буйна растителност и тя също пречи да се види постройката, която иначе е отличен екземпляр на бетонната архитектура от епохата на социализма.

По онова време градската легенда гласеше, че под сградата има тунели, които я свързват с Партийния дом (сега Община Варна) и от които веднага ще излязат бронетранспортьори, „ако стане нещо като в Полша“.

Шансът на един варненски брутализъм — Снимка: Община Варна

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

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

Според нея бившето Руско консулство е образец на архитектурния стил брутализъм, към който се забелязва подчертан интерес в последно време. Сградата е запазена почти в оригиналния си вид от 1979 г., когато е построена по проект на арх. Георги Саваков, а големият скулптор Евгени Баръмов добавя акцент с пластичната композиция на фасадата и с други свои произведения.

Акустични тавани, мозайки и дъбов паркет – примерите за социалистически лукс са оцелели през десетилетията непокътнати, а като имаме предвид, че навремето те са правени за „братушките“, изработката им със сигурност е „първо качество“, както се казваше тогава. Осветлението, което е специално проектирано за мястото, също е запазено в оригиналния си вид. Без да има такъв статус, бившето консулство е на практика архитектурен паметник на една епоха, която все още вълнува хората и в никакъв случай не бива да бъде забравяна.

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

Естествено, без стискане на палци няма да се мине.

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

На фона на все по-обърканата външно-вътрешна политика, демонстрирана от новите управляващи, нищо чудно на някоя умна глава в управляващото мнозинство да ѝ хрумне да „пази“ вече бившето консулство с убеждението, че „руснаците ще се върнат“.

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

Аз лично имам блед спомен, че в детството ми, като пионерче, с класа са ни водили на посещение в Съветското консулство. Смътно си спомням, че може да съм бил там в ранните си репортерски години – или в края на миналия век, или в началото на този. Но така или иначе помня усещането си за мястото. То притежава атмосфера на стилна строгост и вдъхва особено страхопочитание, някак си налага да се държиш по-дисциплинирано. Може би в съзнанието ми е била жива градската легенда за бронетранспортьорите в тунелите отдолу и затова съм се усетил така.

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

Планът на Общината е хрониката на бившето Руско консулство да бъде показана и разказана в новия център за изкуство и култура, така че да се превърне в постоянен и нагледен урок по история. А такъв е нужен, защото спомените на тези, които сме живели в соца, започват да избледняват, а новите поколения оформят виждането си за този исторически период от източници, които почти задължително са размътени от откровена политическа пропаганда, без значение в каква насока.

Trump & Crypto: Last Week Tonight with John Oliver (HBO)

2026-07-27 LastWeekTonight

Post Syndicated from LastWeekTonight original https://www.youtube.com/watch?v=A9iZ10yIRwM

Anti-DDoS managed rule group features

Implementation details

Phase 1: Anti-DDoS managed rule group deployed in Count mode (rolling out July 27–August 7, 2026)

Phase 2: Free evaluation period (July 27–September 30, 2026)

Phase 3: Auto-upgrade begins (October 1, 2026)

Phase 4: Guided migration (available July 27–December 31, 2026)

Phase 5: Shield Advanced application-layer automatic mitigation sunset (January 1, 2027)

Observability

Tier 1: Event detection alarms

Tier 2: Detection labels for custom monitoring

Tier 3: Mitigation action metrics

Observability summary

Billing

Update your infrastructure as code

Update your AWS Firewall Manager policy

Firewall Manager policies using IaC

Getting started

Conclusion

Resources

What is the Cloud Controls Matrix?

Responsibility models

What’s inside the guide

Related resources

Architecture overview

The data lake foundation: Centralized access with Lake Formation

Golden datasets: Shared once, used everywhere

Why Lake Formation?

Orchestration: Amazon Managed Workflows for Apache Airflow (Amazon MWAA)

Athena and AWS Glue: Data access and processing

Amazon SageMaker: Training, inference, and vector search

Training

Batch inference

Vector search

Why SageMaker inside MWAA?

Putting it together: A complete pipeline example

Key patterns in this DAG

Serving layer: DynamoDB + ECS

Extending to real-time

Security and access control

Reliability and failure handling

Lessons learned

Conclusion

About the authors

Why privacy protocols can be hard to debug

Debugging without pvcli

Debugging with pvcli

What pvcli can do

Why build our own tool?

Contribute to pvcli

Въпросите задават Грегъри Сток и Роси Михова

Но! Когато търси, човек намира положителното и оптимистичното дори в цялата тази каша.

Естествено, без стискане на палци няма да се мине.

The collective thoughts of the interwebz