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

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 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.

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:

  1. Build a FAISS index over the candidate catalog.
  2. Query the index with per-customer vectors to find top-K nearest neighbors.
  3. 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:

  1. Receive request with customer ID, marketplace, customer context, and page context.
  2. Read pre-computed recommendations from DynamoDB.
  3. Apply real-time filters (availability, eligibility constraints).
  4. Re-rank based on real-time context signals.
  5. 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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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

Shraddha Anil Naik

Shraddha Anil Naik

Shraddha is a Senior Software Engineer on the Everyday Essentials team at Amazon. She specializes in retrieval and recommendation infrastructure that powers personalized experiences for millions of customers.

Sergii Oborskyi

Sergii Oborskyi

Sergii is a Senior Software Engineer on the Everyday Essentials team at Amazon. He builds online recommendation services that serve product recommendations to millions of customers at high throughput and low latency.

Shawn Liu

Shawn is a Senior Machine Learning Engineer on the Everyday Essentials team at Amazon. He develops and evaluates recommendation models on Amazon SageMaker that power personalized product discovery for millions of customers.

Walter Wong

Walter Wong

Walter is a Software Development Manager in the Everyday Essentials Science org at Amazon. His work focuses on customer understanding and personalization, improving product recommendations for millions of customers across Amazon’s everyday essentials catalog.

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

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.

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

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:

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

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

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:

  1. Client gets public key from the gateway.
  2. Client encrypts the request and sends it to the relay.
  3. Relay removes “who” the client is from the encrypted request, and sends it to the gateway.
  4. Gateway decrypts the request, and sends it to the target.
  5. Target processes the request, and sends a response to the gateway.
  6. Gateway encrypts the response, and sends it to the relay.
  7. Relay sends the encrypted response to the client.
  8. 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.

Contact us if you are interested in using Cloudflare’s OHTTP Relays and Gateways.

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Визуализации: Община Варна

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

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

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

The collective thoughts of the interwebz