A GitHub Issue Title Compromised 4,000 Developer Machines (grith.ai)

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

The grith.ai blog reports
on an LLM prompt-injection vulnerability that led to 4,000 installations of
a compromised version of the Cline utility.

For the next eight hours, every developer who installed or updated
Cline got OpenClaw – a separate AI agent with full system access –
installed globally on their machine without consent. Approximately
4,000 downloads occurred before the package was pulled.

The interesting part is not the payload. It is how the attacker got
the npm token in the first place: by injecting a prompt into a
GitHub issue title, which an AI triage bot read, interpreted as an
instruction, and executed.

[$] The relicensing of chardet

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

Chardet
is a Python module that attempts to determine which character set was used
to encode a text string. It was originally written by Mark Pilgrim, who is
also the author of a number of Python books; the 1.0 release happened in
2006. For many years, this module has been under the maintainership of
Dan Blanchard. Chardet has always been licensed under the LGPL, but, with
the 7.0.0
release
, Blanchard changed the terms to the permissive MIT license.
That has led to an extensive (and ongoing) discussion on when code can be
relicensed against the wishes of its original author, and whether using a
large language model to rewrite code is a legitimate way to strip copyleft
requirements from code.

Buildroot 2026.02 released

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

Peter Korsgaard has
announced version 2026.02
of Buildroot, a tool for generating
embedded Linux systems through cross-compilation. Notable changes
include added support for HPPA, use of the 6.19.x kernel headers by
default, better SBOM generation, and more.

Again a very active cycle with more than 1500 changes from 97 unique
contributors. I’m once again very happy to see so many “new” people next
to the “oldtimers”.

See the changelog
for full details. Thanks to Julien Olivain for pointing us to the announcement.

Gigabyte AI TOP ATOM NVIDIA GB10 Review A Neat Little Box

Post Syndicated from Ryan Smith original https://www.servethehome.com/gigabyte-ai-top-atom-nvidia-gb10-review-a-neat-little-box/

The Gigabyte AI TOP ATOM is the company’s NVIDIA GB10 platform for local AI with 128GB, a Blackwell GPU, 200GbE networking, and a fast Arm CPU

The post Gigabyte AI TOP ATOM NVIDIA GB10 Review A Neat Little Box appeared first on ServeTheHome.

AWS completes the 2026 annual Dubai Electronic Security Centre (DESC) certification audit

Post Syndicated from Tariro Dongo original https://aws.amazon.com/blogs/security/aws-completes-the-2026-annual-dubai-electronic-security-centre-desc-certification-audit/

We’re excited to announce that Amazon Web Services (AWS) has completed the annual Dubai Electronic Security Centre (DESC) certification audit to operate as a Tier 1 Cloud Service Provider (CSP) for the AWS Middle East (UAE) Region.

This alignment with DESC requirements demonstrates our continued commitment to adhere to the heightened expectations for CSPs. Government customers of AWS can run their applications in AWS Cloud-certified Regions with confidence.

The AWS compliance to the DESC Framework requirements were validated by an independent third-party auditor (BSI) prior to issuance of a renewed certificate by DESC. The updated DESC CSP certificate is available through AWS Artifact, and is valid for one year to January 22, 2027. AWS Artifact is a self-service portal for on-demand access to AWS compliance reports. Sign in to AWS Artifact in the AWS Management Console, or learn more at Getting Started with AWS Artifact.

The certification includes the following 10 additional services in scope, for a total of 108 services:

This is a 10% increase in the number of services in the Middle East (UAE) Region that are in scope of the DESC CSP certification.

AWS strives to continuously bring services into the scope of its compliance programs to help you meet your architectural and regulatory needs. You can view the current list of services in scope on our Services in Scope page. You can also reach out to your AWS account team if you have any questions or feedback about DESC compliance.

To learn more about our compliance and security programs, see AWS Compliance Programs. As always, we value your feedback and questions; reach out to the AWS Compliance team through the Contact Us page.

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

Tariro Dongo
Tariro Dongo

Tari is a Security Assurance Program Manager at AWS, based in London. Tari is responsible for third-party and customer audits, attestations, certifications, and assessments across EMEA. Previously, Tari worked in security assurance and technology risk in the big four and financial services industry over the last 15 years.

Standardizing construct properties with AWS CDK Property Injection

Post Syndicated from Marco Frattallone original https://aws.amazon.com/blogs/devops/standardizing-construct-properties-with-aws-cdk-property-injection/

Standardizing CDK construct properties across a large organization requires repetitive manual effort that scales poorly as teams and repositories grow. Development teams working with AWS Cloud Development Kit (AWS CDK) must apply the same configuration properties across similar resources to meet security, compliance, and operational standards but manual configuration leads to drift, maintenance burden, and compliance gaps. In this post, you learn how to use Property Injection, a feature introduced in AWS CDK v2.196.0, to automatically apply default properties to constructs without modifying existing code.

The Challenge of Infrastructure Standardization

Organizations implementing infrastructure as code face a fundamental tension between developer productivity and operational consistency. CDK provides abstractions for defining cloud resources, but ensuring compliance with organizational security policies, compliance requirements, and operational standards requires repetitive manual configuration.
Consider this scenario: an organization’s security policy requires that all SecurityGroups disable outbound traffic by default. Development teams must apply these settings to every SecurityGroup:


new SecurityGroup(stack, 'api-sg', {
  vpc: myVpc,
  allowAllOutbound: false,        // Required by security policy
  allowAllIpv6Outbound: false     // Required by security policy
});

new SecurityGroup(stack, 'db-sg', {
  vpc: myVpc,
  allowAllOutbound: false,        // Same configuration repeated
  allowAllIpv6Outbound: false     // Same configuration repeated
});

This manual approach creates four specific problems:

  • Configuration drift: Teams omit required properties or apply them inconsistently
  • Maintenance burden: Policy updates require coordinated changes across multiple repositories and teams
  • Developer friction: Repetitive configuration tasks slow development velocity and increase cognitive load
  • Compliance gaps: Manual processes introduce human error, creating security or compliance violations

Custom construct libraries address these challenges but require refactoring every construct instantiation in existing code and create learning curves for development teams already familiar with standard CDK patterns.

Introducing Property Injection

AWS CDK Property Injection addresses these challenges by automatically applying default properties to constructs without requiring changes to existing code.

Property Injection is a feature introduced in AWS CDK v2.196.0 that intercepts construct creation and automatically applies organizational defaults. With this approach, you can enforce standards consistently while preserving existing development workflows and code patterns.

After implementing Property Injection, the same SecurityGroup creation requires only the vpc parameter, security defaults are applied automatically:

// Your existing code remains unchanged
new SecurityGroup(stack, 'my-sg', {
  vpc: myVpc
  // Security defaults applied automatically by Property Injection
});

The key benefits of this approach include:

  • Zero-impact adoption: Existing CDK code continues to work without modification
  • Centralized policy management: Standards are defined once and applied automatically
  • Consistent enforcement: Policies are applied uniformly across all applications and teams
  • Reduced maintenance overhead: Policy updates require changes in only one location
This diagram shows the five-step Property Injection process in a clear two-column format. The left column outlines each process step, while the right column shows the corresponding implementation details with properly formatted TypeScript code. The flow demonstrates how CDK intercepts SecurityGroup creation, applies organizational security defaults through property injectors, merges them with developer-specified properties, and creates a fully configured SecurityGroup that meets both developer requirements and organizational standards.

Figure 1: CDK Property Injection Mechanism

Property Injection operates transparently within CDK, intercepting construct creation to apply predefined defaults before merging them with any properties explicitly provided by developers. This ensures that organizational standards are consistently applied while maintaining the flexibility for developers to override defaults when specific use cases require it.

Understanding the Implementation Approach

Property Injection works by implementing the IPropertyInjector interface, which allows you to define default properties for specific construct types. These injectors are registered with CDK stacks and automatically apply their defaults during construct instantiation.
The implementation follows three steps: define the defaults you want to apply, register the injector with your stack, and let CDK handle the automatic application of these defaults to matching constructs.

Implementation Guide

This section shows you how to implement Property Injection for SecurityGroup constructs.

Step 1: Create a Property Injector

Create a class that implements the IPropertyInjector interface:

import { IPropertyInjector, InjectionContext } from 'aws-cdk-lib';
import { SecurityGroup, SecurityGroupProps } from 'aws-cdk-lib/aws-ec2';

export class SecurityGroupDefaults implements IPropertyInjector {
  readonly constructUniqueId: string;

  constructor() {
    this.constructUniqueId = SecurityGroup.PROPERTY_INJECTION_ID;
  }

  inject(originalProps: SecurityGroupProps, context: InjectionContext): SecurityGroupProps {
    return {
      // Apply organizational defaults
      allowAllIpv6Outbound: false,
      allowAllOutbound: false,
      // Original properties override defaults when specified
      ...originalProps,
    };
  }
}

Step 2: Add the Injector to Your Stack

Apply the injector to your CDK stack:

import { Stack } from 'aws-cdk-lib';
import { SecurityGroupDefaults } from './security-defaults';

const stack = new Stack(app, 'MyStack', {
  propertyInjectors: [
    new SecurityGroupDefaults()
  ]
});

Step 3: Use Constructs Normally

Create constructs as usual. The injector applies defaults automatically:

// This SecurityGroup receives the injected defaults:
// - allowAllOutbound: false
// - allowAllIpv6Outbound: false
new SecurityGroup(stack, 'my-sg', {
  vpc: myVpc
});

// You can override defaults when necessary
new SecurityGroup(stack, 'special-sg', {
  vpc: myVpc,
  allowAllOutbound: true  // Overrides the injected default
});
This side-by-side comparison shows the difference between manual configuration and Property Injection. The left side (Before) shows three SecurityGroup definitions, each requiring manual specification of allowAllOutbound: false and allowAllIpv6Outbound: false, leading to repetitive code, inconsistency risk, and maintenance burden. The right side (After) shows the same SecurityGroups created with the VPC parameter alone after a one-time Property Injection setup, demonstrating the DRY principle, consistent defaults, and reduced maintenance.

Figure 2: CDK Code Before vs After Property Injection

Property Injection vs L2 Constructs

You can achieve the same enforcement of default properties by creating custom L2 constructs with built-in defaults. However, Property Injection is better suited for standardizing existing codebases without refactoring, while L2 Constructs are better suited for new projects where you want custom APIs and multi-resource abstractions.

This decision tree guides the selection between Property Injection and L2 Constructs for CDK standardization. Starting with existing CDK applications, it evaluates willingness to accept potential breaking changes from new defaults. If breaking changes are acceptable or no existing code exists, it assesses whether custom APIs, naming improvements, or multi-resource patterns are needed beyond simple defaults. The tree leads to three outcomes: Property Injection (blue) for transparent defaults with existing code compatibility, L2 Constructs (orange) for custom APIs and purpose-built abstractions, or a Hybrid approach (green) combining both techniques for maximum flexibility.

Figure 3: Decision Tree – Property Injection vs L2 Constructs

Implementation Comparison

Consider an application with multiple SecurityGroup instantiations that need standardized security defaults.

L2 Construct approach requires creating a custom construct and updating each instantiation:

// Step 1: Create custom L2 construct
export class SecureSecurityGroup extends SecurityGroup {
  constructor(scope: Construct, id: string, props: SecurityGroupProps) {
    super(scope, id, {
      allowAllOutbound: false,
      allowAllIpv6Outbound: false,
      ...props
    });
  }
}

// Step 2: Update each instantiation throughout your codebase
// Change from:
new SecurityGroup(stack, 'sg1', { vpc: myVpc })
new SecurityGroup(stack, 'sg2', { vpc: myVpc })
new SecurityGroup(stack, 'sg3', { vpc: myVpc })

// To:
new SecureSecurityGroup(stack, 'sg1', { vpc: myVpc })
new SecureSecurityGroup(stack, 'sg2', { vpc: myVpc })
new SecureSecurityGroup(stack, 'sg3', { vpc: myVpc })

Property Injection approach requires one-time stack configuration:

// Step 1: Add injector to stack configuration
stack.propertyInjectors = [new SecurityGroupDefaults()];

// Step 2: Existing SecurityGroup calls receive defaults automatically
new SecurityGroup(stack, 'sg1', { vpc: myVpc })  // Gets defaults
new SecurityGroup(stack, 'sg2', { vpc: myVpc })  // Gets defaults  
new SecurityGroup(stack, 'sg3', { vpc: myVpc })  // Gets defaults

Key Differences

Property Injection works with existing construct calls, requiring no changes to how developers instantiate SecurityGroups or other constructs. This approach overrides constructs from external libraries and can be implemented without modifying existing code. Developers continue using familiar CDK APIs without learning new interfaces.

L2 Constructs require updating all constructor calls throughout your codebase. This approach cannot modify third-party construct creation since you must change each instantiation to use your custom construct. Implementation requires refactoring existing code and developers must learn your custom construct APIs instead of standard CDK interfaces. L2 constructs serve multiple purposes beyond complex business logic – simple L2 constructs provide domain-specific naming conventions and cleaner APIs, while complex L2 constructs orchestrate three or more resources and implement business rules.

When to Choose Each Approach

Choose Property Injection when you need to standardize existing infrastructure. Property Injection excels in scenarios where you already have CDK applications deployed and need to apply consistent defaults retroactively. Property Injection works transparently with existing code, requiring no changes to how developers instantiate constructs. This makes it useful when you have existing CDK applications that you want to standardize without disrupting current development workflows.

Property Injection also solves the challenge of applying defaults to constructs from third-party libraries. Since you cannot modify external library code, Property Injection enforces organizational standards on any construct type, regardless of its source. Additionally, when you want to implement standards without changing existing code, Property Injection operates at the framework level, automatically applying defaults during construct instantiation without requiring developers to modify their existing implementations.

Choose L2 Constructs when you need custom APIs or multi-resource patterns. L2 Constructs provide the right abstraction when you want to create purpose-built interfaces that differ from standard CDK APIs. This includes simple wrappers with domain-specific naming, complex business logic, validation rules, or multi-resource orchestration patterns. L2 Constructs excel when you want to create opinionated APIs that simplify common patterns by hiding complexity behind intuitive interfaces.

L2 Constructs suit new application development where you can design the API from the start. This approach creates purpose-built abstractions that match your organization’s specific use cases and terminology. Unlike Property Injection, which applies defaults to existing construct APIs, with L2 Constructs you can design entirely new APIs that directly represent your business domain and operational patterns.

Implementation Patterns

Stack Integration Methods

The CDK provides two methods for adding Property Injectors to stacks:

This diagram demonstrates two methods for adding Property Injectors to CDK stacks. Method 1 (blue) shows adding injectors directly in the Stack constructor’s propertyInjectors array. Method 2 (orange) shows using PropertyInjectors.of(stack).add() after stack creation. Both methods produce identical results with green checkmarks indicating success. The diagram includes usage examples showing normal SecurityGroup instantiation (blue) that inherits defaults automatically, and override scenarios (orange) where developers explicitly override injected defaults. The bottom section shows the resulting CloudFormation output: default SecurityGroups have empty egress rules (green), while overridden ones include outbound traffic rules (orange).

Figure 4: CDK Stack Integration Methods

Method 1: Stack Constructor

const stack = new Stack(app, 'MyStack', {
  propertyInjectors: [new SecurityGroupDefaults()]
});

Method 2: PropertyInjectors.of()

const stack = new Stack(app, 'MyStack');
PropertyInjectors.of(stack).add(new SecurityGroupDefaults());

Both methods produce the same result. Choose the method that best fits your existing code structure. For more details, see the PropertyInjectors API documentation.

Organization-Wide Implementation

For organization-wide standardization, create a shared library of injectors:

// @myorg/cdk-injectors package
export const ORGANIZATION_INJECTORS: IPropertyInjector[] = [
  new SecurityGroupDefaults(),
  new LambdaFunctionDefaults(),
  new S3BucketDefaults(),
];

// Teams import and use the shared injectors
import { ORGANIZATION_INJECTORS } from '@myorg/cdk-injectors';

const stack = new Stack(app, 'TeamStack', {
  propertyInjectors: ORGANIZATION_INJECTORS
});

Scope Hierarchy

Property Injectors can be applied at different levels in the CDK construct tree:

This diagram illustrates the three-level hierarchy of Property Injector scopes in CDK with integrated resolution examples. The App level (blue) shows a BucketInjector ‘b1’ that applies globally, with an example showing how Stack2 buckets use this injector. The Stage level (green) demonstrates a FunctionInjector ‘f1’ that applies to all stacks within the stage, including an example of Stack1 functions using this injector. The Stack level (orange) shows two stacks: Stack1 with its own BucketInjector ‘b2’ that overrides the app-level injector, and Stack2 with no injectors that inherits from parent scopes. The Resolution Rules box (green) explains that CDK searches from most specific (stack) to most general (app), with the first match winning per construct type. Arrows show the hierarchical relationship between scopes.

    Figure 5: CDK Scope Hierarchy & Injector Resolution
  • App level: Applies to all stacks in the application
  • Stage level: Applies to all stacks within a specific stage
  • Stack level: Applies only to constructs within a specific stack

CDK searches for applicable injectors starting from the construct’s immediate parent scope and moving upward. The first matching injector for each construct type is used.

Best Practices

When implementing Property Injection, begin with high-impact constructs like SecurityGroups, VPCs, and Lambda functions that require repetitive configuration.

These constructs have the highest frequency of misconfiguration and the most direct compliance impact, making them the most valuable targets for early adoption.

Document your defaults by explaining what properties your injectors provide and why. Include examples and link to relevant policies that drive the requirements. With this documentation, developers can understand standards and make informed override decisions.

Write automated tests using CDK testing utilities to verify that injectors apply expected defaults. Test both standard scenarios and cases where developers override properties to prevent regressions when updating injector logic.

Version injectors carefully using semantic versioning principles because changes affect all applications. Coordinate updates across teams and provide migration guides for breaking changes or changes to default values.

Design override mechanisms so that developers can handle edge cases while benefiting from organizational standards. Property Injection operates as defaults, not restrictions, so design injectors to merge gracefully with developer-specified properties.

Limitations and Considerations

Property Injection operates as a default mechanism rather than a compliance enforcement system. Developers retain the ability to override injected properties, which means organizations cannot rely solely on Property Injection for strict compliance requirements. For teams that need mandatory compliance, combine Property Injection with CDK Aspects or AWS Config rules to validate and enforce standards.

The feature works exclusively with L2 constructs, as documented in the official AWS CDK guidance. The IPropertyInjector interface targets specific L2 construct types, and L1 (CloudFormation) constructs use different instantiation patterns that bypass the property injection mechanism entirely. Organizations with L1 construct usage need alternative standardization approaches.

Property Injection introduces debugging complexity because injected properties do not appear directly in application code. Developers troubleshooting construct behavior must understand which injectors apply to specific construct types and how those injectors modify properties. This hidden behavior requires documentation that lists each injector, the properties it sets, and the policy it enforces, along with clear naming conventions to maintain code clarity.

The feature requires CDK v2.196.0 or later, which affects adoption timelines for organizations using older CDK versions. Teams must plan upgrade paths and test compatibility before implementing Property Injection across their applications.

Conclusion

Property Injection provides a mechanism for applying consistent default properties to CDK constructs without requiring changes to existing code. This approach reduces repetitive configuration, improves consistency, and simplifies maintenance of CDK applications.
Property Injection is the right choice for organizations that need to standardize construct configurations across existing codebases while preserving developer workflows. When combined with proper testing and documentation, Property Injection becomes a reliable foundation for infrastructure governance across your organization.

About the authors:

Put Cheung

Put Cheung is a Senior Software Development Engineer at AWS Security. He is a part of a team that is making it easier for builders to configure AWS Resources securely. AWS CDK Property Injection is an important step toward this goal.

Rico Huijbers

Rico Huijbers is a Software Engineer at Amazon Web Services. He is extremely lazy and is therefore on a quest to eradicate the need for repetitive manual work from software engineering. Rico loves working on AWS CDK—it’s the tool he wishes he had 5 years earlier.

Marco Frattallone

Marco Frattallone is a Senior Technical Account Manager at AWS focused on supporting Partners. He works closely with Partners to help them build, deploy, and optimize their solutions on AWS, providing guidance and leveraging best practices. Marco focuses on helping Partners adopt emerging AWS services and translate technical capabilities into business outcomes. Outside work, he enjoys outdoor cycling, sailing, and exploring new cultures.

Israel Hacked Traffic Cameras in Iran

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/03/israel-hacked-traffic-cameras-in-iran.html

Multiple news outlets are reporting on Israel’s hacking of Iranian traffic cameras and how they assisted with the killing of that country’s leadership.

The New York Times has an on the intelligence operation more generally.

Adding a voice layer to WhatsApp conversations with AWS End User Messaging

Post Syndicated from Pavlos Ioannou Katidis original https://aws.amazon.com/blogs/messaging-and-targeting/adding-a-voice-layer-to-whatsapp-conversations-with-aws-end-user-messaging/

Businesses around the world use WhatsApp as a primary channel to connect with customers. It’s familiar, trusted, and effective for everything from booking confirmations to customer support. But most of these conversations are still text-only. For many customers, text is fast and efficient. Yet there are times when typing is inconvenient, slow, or less effective at conveying nuance. In those moments, voice messages can transform the interaction — making it faster, more inclusive, and more human.

With AWS End User Messaging, businesses can now enable both voice note input and voice note responses on WhatsApp. Customers send a voice note, and a bot can respond with a natural-sounding voice note reply. Note: This solution processes asynchronous voice notes (recorded audio messages), not real-time voice calls. In this blog post, we explore why voice notes matter, where they make a difference, and how AWS helps you enable them through a sample voice note messaging solution.

Watch an end to end demo here.

Why voice notes matter in customer messaging

Text remains essential, but research shows that voice notes adds unique advantages:

  • Richer communication: Voice carries tone, urgency, and emotion — reducing misunderstandings and helping businesses respond more appropriately (Preply survey).
  • Natural and fast: Speaking is up to three times faster than typing on mobile devices, especially when users are on the go (Sherry Ruan, Jacob O. Wobbrock, Kenny Liou, Andrew Ng, and James A. Landay. 2018. Comparing Speech and Keyboard Text Entry for Short Messages in Two Languages on Touchscreen Phones. Proc. ACM Interact. Mob. Wearable Ubiquitous Technol. 1, 4, Article 159 (December 2017), 23 pages. https://doi.org/10.1145/3161187).
  • Accessibility and inclusivity: Voice lowers barriers for people with limited literacy or visual impairments. Elderly customers or those with difficulty reading long text messages benefit significantly.
  • Context-driven preference: A YouGov study across 17 markets found that while text is still preferred overall, a notable share of users choose both text and audio depending on situation (YouGov survey).

Where voice notes make a difference

Voice messaging is especially useful when speaking feels more natural than typing—helping customers communicate in ways that fit their situation and needs.

  • Elderly customers – easier to listen than to read.
  • Field workers or drivers – easier to speak than to type while working.
  • Healthcare – patients can describe symptoms naturally by voice.
  • Hospitality and reservations – “Book a table for 7 pm” is faster to say than to navigate online calendar.
  • Customer support escalation – complex issues are often resolved more quickly with a voice exchange.

Voice notes don’t replace text. It complements it — giving customers the flexibility to communicate in the way that best suits their context.

AWS End User Messaging and WhatsApp

AWS End User Messaging is a managed AWS service that enables businesses to send and receive messages across multiple channels, including WhatsApp, SMS, MMS (US only), outbound voice, and push notifications.

When you use AWS End User Messaging for WhatsApp, you benefit from AWS’s global scale, resilience, and security. Inbound WhatsApp messages are automatically published to an Amazon SNS topic, enabling the integration with other AWS services such as Amazon SQS queues, AWS Lambda functions or Amazon Bedrock for downstream processing.

This flexibility is also what makes voice-to-voice messaging possible. Businesses can process inbound voice messages with Lambda, apply speech-to-text and text-to-speech services like Amazon Transcribe and Amazon Polly, or integrate third-party models such as Whisper through the AWS Marketplace for Amazon Bedrock.

Voice notes messaging solution

To demonstrate how voice can be enabled on WhatsApp, check out the AWS CDK sample project:  GitHub – WhatsApp Voice Notes Messaging

The solution shows how to:

  • Receive a WhatsApp voice note through AWS End User Messaging.
  • Transcribe the voice input to text.
  • Process it with conversational bot logic.
  • Convert the response back into a natural-sounding voice note.
  • Send the reply to the user on WhatsApp.

You can enable inbound only, outbound only, or a full voice-to-voice  notes loop depending on your requirements.

Getting started

The complete solution is available as an open-source AWS CDK project. To get started, you’ll need:

Implementation

Clone the repository and deploy the solution:

git clone https://github.com/aws-samples/sample-whatsapp-voice-to-voice-messaging
cd sample-whatsapp-voice-to-voice-messaging
npm install

Before deploying, you’ll need to configure your WhatsApp phone number ID in the CDK context or parameters. The deployment will prompt you for this configuration, or you can set it in the cdk.json file. Once configured, deploy with:

cdk deploy

The CDK stack automatically provisions all required AWS resources including Lambda functions, SNS topics, S3 buckets, and IAM roles.

Clean up

To remove all resources and avoid ongoing charges:

cdk destroy

For detailed architecture diagrams, configuration options, and step-by-step setup instructions, visit the GitHub repository.

Conclusion

Customers are already using voice notes in their personal WhatsApp conversations. Bringing that same option into business communication makes customer interactions more natural, inclusive, and efficient.

With AWS End User Messaging and its WhatsApp channel, you can add voice alongside text without changing how customers connect to you. And with the sample CDK project, you can try it out today, experiment, and extend it for your own business needs.

Explore the project here: AWS Sample – WhatsApp Voice Notes Messaging


About the authors

Back Up Your Entire OpenClaw State to Backblaze B2

Post Syndicated from Jeronimo De Leon original https://www.backblaze.com/blog/back-up-your-entire-openclaw-state-to-backblaze-b2/

A decorative image showing a series of 0s and 1s.

There’s a new open-source plugin that snapshots your OpenClaw config, memory, and sessions to B2. It’s designed to be as simple as possible: Three fields to configure. Rollback from chat. Migrate to a new machine in one restart. 

Let’s get into how and why you might want to use it.

OpenClaw keeps everything local. That’s great until it isn’t.

Your config, sessions, memory databases, hooks, cron jobs—everything that makes your OpenClaw instance yours lives on one machine with no built-in redundancy. Compaction can rewrite session transcripts and cause memory loss. A bad config edit or an accidental deletion means rebuilding from scratch: re-onboarding channels, re-pairing devices, re-teaching your agent who you are.

openclaw-b2-backup adds automatic encrypted backups to Backblaze B2 without changing how you use OpenClaw.

Three fields and you’re done

Setup is intentionally minimal:

openclaw plugins install openclaw-b2-backup

Then open ~/.openclaw/openclaw.json and add your B2 credentials to the entry the installer created:

{
"openclaw-b2-backup": {
"enabled": true,
"config": {
"keyId": "004a...",
"applicationKey": "K004...",
"bucket": "my-openclaw-backups"
}
}
}

Restart the gateway, and you’re done. Region is auto-detected from your application key. Encryption is on by default. The first backup runs at midnight, and then daily after that. You can change the schedule to weekly or any cron expression you like.

Free tier friendly: Backblaze B2 includes 10GB of free storage. A typical OpenClaw state directory is 50–500 MB, so even with 10 encrypted snapshots retained, you’ll comfortably stay within the free tier.

Backups that actually happen

The hardest part of any backup system is remembering to run it. This plugin takes care of that with multiple automatic triggers:

  • A daily cron job (configurable) runs a full incremental push at midnight. 
  • Every time you shut down the gateway, a final push runs before exit—so you always have a snapshot of your latest state. 
  • And, before compaction fires (the thing that rewrites your session transcripts and can cause memory loss), the plugin automatically pushes a snapshot. That last one is the one you’ll be most grateful for.

There’s a 5-minute debounce on the compaction trigger, so rapid-fire compactions don’t queue up a dozen pushes.

Rolling back from chat

The plugin registers a b2_rollback tool with your agent, which means you can manage backups conversationally. Just tell your agent:

“Show me my B2 backup snapshots”

And it’ll list all available snapshots with timestamps. To restore one:

“Roll back to the snapshot from before compaction”Before any restore, the plugin automatically creates a safety snapshot of your current state. Safety snapshots are stored separately and never auto-pruned, so you can always recover from a bad rollback. It’s an undo for your undo.

Moving to a new machine

This was one of the most requested use cases: Getting your entire OpenClaw setup onto a new machine without manually copying files and hoping you got everything.

Install the plugin on your new machine, add the same B2 credentials, and restart. The plugin detects the empty state directory, finds your existing snapshots in B2, and automatically restores the latest one. Same memory, same sessions, same config, same personality. No manual file copying.

openclaw plugins install openclaw-b2-backup
# Add your B2 config to openclaw.json
openclaw gateway restart
# Plugin detects empty state + existing snapshots → auto-restores latest

Security by default

Everything is AES-256-GCM encrypted before it leaves your machine. Each file gets a random salt and IV, so identical files produce different ciphertext. The encryption key is derived from your B2 application key via scrypt—no separate key to manage or lose.

Manifests (which contain only file paths and SHA-256 hashes) stay unencrypted so incremental diffing works regardless of encryption. Credentials and auth profiles are excluded from sync by design—secrets stay per-machine, and you re-auth on new machines.

Best practice: Use a B2 application key scoped to a single bucket for least-privilege access. The plugin works perfectly with bucket-scoped keys—region is auto-detected from the authorize response.

Zero external dependencies

The plugin has no external runtime dependencies beyond croner for scheduling. The B2 client is a hand-rolled AWS Signature V4 implementation using only node:crypto. No AWS SDK, no S3 library, no heavyweight dependencies to audit or keep updated.

It runs entirely inside the gateway process—no external scripts, no separate cron daemon, no stopping the gateway to take backups.

Get started

The plugin is open source (under the MIT license) and available now:

openclaw plugins install openclaw-b2-backup

Source code and full documentation: github.com/backblaze-b2-samples/openclaw-b2-sync-backup

npm package: npmjs.com/package/openclaw-b2-backup

If you run into issues or have feature requests, open an issue on GitHub. And if this plugin saves you from a rebuild, we’d love to hear about it.

The post Back Up Your Entire OpenClaw State to Backblaze B2 appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

[$] Reconsidering the multi-generational LRU

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

The multi-generational LRU (MGLRU) is an
alternative memory-management algorithm that was merged for the 6.1 kernel
in late 2022. It brought a promise of much-improved performance and
simplified code. Since then, though, progress on MGLRU has stalled, and it
still is not enabled on many systems. As the 2026 Linux Storage,
Filesystem, Memory-Management and BPF Summit
(LSFMM+BPF) approaches,
several memory-management developers have indicated a desire to talk about
the future of MGLRU. While some developers are looking for ways to improve
the subsystem, another has called for it to be removed entirely.

From Code to Runtime: The Critical Role of DAST in Application Security

Post Syndicated from Xavia Hennessy original https://www.rapid7.com/blog/post/cds-code-to-runtime-dast-in-application-security

Regardless of where you’re at in your application security maturity, dynamic application security testing (DAST) is a program staple in a few key ways:

  1. It satisfies compliance requirements for runtime-related vulnerabilities. 

  2. DAST catches vulnerabilities in the running web application, yielding findings that may be missed in static code testing.

  3. It is security-driven with little overhead in configuration/maintenance from development or application teams.

Due to the nature of web apps powering mission-critical operations – hyperscaled of course by AI protocols that automate key processes within these apps – continuous DAST is essential to identifying and remediating potential weaknesses that could quickly lead to costly data breaches.

Compliance requirements

DAST helps satisfy multiple compliance requirements by simulating real-world attacks so it can test a running application for vulnerabilities.. While DAST alone doesn’t make you compliant, it supports key controls in many security standards and regulations. Get to know 7 of today’s top standards and frameworks, see which requirements they satisfy, and learn how DAST helps secure the following:

PCI DSS

Payment Card Industry Data Security Standard (PCI DSS) is the global security standard for any organization that stores, processes, or transmits payment-card data. DAST directly supports PCI compliance by performing vulnerability scans against live web apps.

Requirements satisfied: 

  • Requirement 6.1 & 6.2: Identifying and addressing vulnerabilities.

  • Requirement 6.6: All public-facing web applications must be either:

    • Protected with application-layer firewall (WAF), or

    • Tested for vulnerabilities (e.g., via DAST) at least annually.


OWASP Top Ten

While the Open Worldwide Application Security Project (OWASP) is not a compliance framework, the nonprofit organization is often referenced by industry and regulatory standards. 

Requirements satisfied:

  • DAST tools are often tested against OWASP Top 10 vulnerabilities (e.g., XSS, SQLi, SSRF).


HIPAA

The Health Insurance Portability and Accountability Act (HIPAA) sets national standards for protecting electronic protected health information (ePHI). DAST supports risk assessment by identifying live vulnerabilities with the potential to expose such information.

Requirements satisfied: 

  • Security Rule (45 CFR § 164.308 & § 164.312):

    • Requires organizations to perform regular risk assessments.

    • Includes application-level vulnerabilities as part of overall system security.


ISO/IEC 27001

ISO/International Electrotechnical Commission (ISO/IEC) is the international standard that specifies requirements for an information security management system (ISMS). DAST helps fulfill this requirement by scanning running applications for known and exploitable vulnerabilities.

Requirements satisfied: 

  • Annex A.12.6.1: Management of technical vulnerabilities – Requires timely detection and remediation of vulnerabilities.


NIST SP 800-53/800-171

The National Institute of Standards and Technology (NIST) is a U.S. federal agency that develops measurement science, standards, and tech to boost innovation and economic security. DAST can be used to meet these technical controls.

Requirements satisfied: 

  • RA-5 (vulnerability scanning): Requires scanning of systems and applications.

  • SI-2 (faw remediation): Identify, report, and fix flaws in software.


SOC 2

System and Organization Controls 2 (SOC2) is an independent attestation report (from a licensed CPA firm) that evaluates whether a service organization’s controls are suitably designed. DAST contributes evidence for audit logs and control effectiveness over time.

Requirements satisfied: 

  • Under the “Security” Trust Services Criteria, particularly:

    • CC4.1: Monitor infrastructure for new threats.

    • CC7.1/CC7.2: Detect and mitigate vulnerabilities.


GDPR

General Data Protection Regulation (GDPR) harmonizes privacy rules across the EU and sets requirements for how organizations collect, use, share, and protect personal data. DAST can be part of regular security testing under GDPR, especially if the app processes personal data.

Requirements satisfied: 

  • Article 32 – Security of Processing:

    • Organizations must ensure the ongoing confidentiality, integrity, availability of systems.

    • Requires regular testing and evaluation of security measures.

Missed findings

Static application security testing (SAST) tools are effective at flagging insecure values on their own, but they often miss the broader application context needed to assess whether those values actually introduce risk. Here are some examples of findings that can be overlooked:

Forced browsing

Forced browsing (also called insecure direct object reference or unauthorized resource access) occurs when:

  • A user can manually access restricted resources (files, endpoints, or actions) by guessing or modifying a URL.

  • There are missing access controls or authorization checks.

Example: A user modifies a URL

https://example.com/admin/settings

Even though they’re not an admin, the app still serves the page because it lacks proper access controls.

SAST struggles to detect these findings due to:

  • Lack of visibility into runtime access control

    • SAST scans source code, but can’t simulate user roles or sessions.

    • It doesn’t know who should or shouldn’t be able to access a specific path.

  • Abstracted access control logic

    • Authorization might be handled via middleware, annotations, config files, or external services (e.g., OAuth).

    • SAST often can’t follow the full enforcement logic, especially if it’s custom or dynamic.

  • Lack of awareness around routing and resource exposure

    • SAST doesn’t map which endpoints exist versus which are intended to be public.

    • It can’t verify which files/resources are accessible through URLs.

Out-of-band (OOB) cross-site scripting (XSS)

Out-of-band cross-site-scripting OOB XSS (a subtype of stored or blind XSS) occurs when:

  • A malicious script is injected into an application (e.g., a form, comment, or field).

  • The script doesn’t execute immediately but instead fires later, often:

    • In a different user’s browser (e.g., an admin viewing logs).

    • In an email client (e.g., via notification messages).

    • In a third-party system or admin dashboard.

These attacks are asynchronous and context-shifted, meaning they don’t happen in the direct request-response flow. SAST struggles to detect these findings due to:

  • Missing runtime context: SAST analyzes source code statically, line by line, without executing it. It doesn’t track:

    • Where the injected payload ends up.

    • How or where it’s later rendered.

    • Whether it’s rendered in a dangerous context (HTML, JS, email, etc.).

  • Visibility is limited to code flow: SAST typically can’t follow data across storage layers or external systems. OOB XSS often spans:

    • User-submitted input → stored in DB.

    • Later retrieved → rendered in admin UI or email.

  • Unable to observe execution: The XSS payload doesn’t fire in the original request, so SAST has no way to “see” the exploit being triggered because it doesn’t execute code.

Web config findings

Settings defined in the web config file can pose challenges for SAST tools. Depending on the tooling, these files may not be properly parsed, potentially causing the tool to miss important findings due to a lack of contextual understanding, such as:

Custom error handling depends on deployment mode

<customErrors mode="RemoteOnly" />

⠀
✔ Looks fine in static analysis; it shows friendly errors to remote users.

✖ Contextual issue: If the app is misconfigured to treat all users as local, then stack traces are exposed even with this setting.

SSL enforcement logic in code, not in config.

<rewrite>
<!-- Missing rule for HTTPS redirection -->
</rewrite>

⠀
✔ SAST flags the absence of HTTPS redirection in web.config, which is a valid finding.

✖  Contextual issue: If HTTPS redirection is handled in middleware or at a reverse proxy (like NGINX or Azure App Gateway), then this isn’t actually a security risk. SAST can’t always know that.

Authentication mode

<authentication mode="None" />

⠀
✔ SAST will likely flag this as a critical issue.

✖  Contextual issue: If the app is a microservice behind an API gateway that handles auth, this may be acceptable. A SAST tool unaware of deployment architecture may raise false positives.

Debug enabled in a non-prod environment

<compilation debug="true" />

⠀
✔ Flagged by SAST, correctly so in most cases.

✖ Contextual issue: If this web.config is only used in a staging or development slot, it might be intentional and not a production risk.

Authorization settings ignored in custom pipelines

<authorization>
  <deny users="?" />
</authorization>

⠀

✔ This looks like it blocks anonymous access.

✖ Contextual issue: If a custom authentication mechanism bypasses ASP.NET authorization modules, this setting may be ineffective, but a SAST tool won’t see that unless it’s deeply integrated with the entire codebase.

Developer overhead

For organizations seeking to minimize developer burden, DAST is frequently the preferred option over SAST.  DAST processes evolve alongside your web applications, continuing to scan them so that your business can promptly identify and remediate emerging issues. Let’s finish by taking a look at a range of underlying dynamics that make DAST an easy decision for developers looking to fortify application security – table below.

⠀

Developer-overhead-DAST-capability-chart.png

Security updates for Thursday

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

Security updates have been issued by AlmaLinux (go-rpm-macros, libpng, thunderbird, udisks2, and valkey), Fedora (coturn, php-zumba-json-serializer, valkey, and yt-dlp), Red Hat (delve, go-rpm-macros, grafana, grafana-pcp, image-builder, osbuild-composer, and postgresql), Slackware (nvi), SUSE (firefox, glibc, haproxy, kernel, kubevirt, libsoup, libsoup2, libxslt, mozilla-nss, ocaml, python, python-Django, python-pip, util-linux, virtiofsd, wicked2nm,suse-migration-services,suse-migration- sle16-activation,SLES16-Migration,SLES16-SAP_Migration, and wireshark), and Ubuntu (gimp, linux-aws, linux-lts-xenial, linux-aws-fips, linux-azure, linux-azure-fips, linux-fips, nss, postgresql-14, postgresql-16, postgresql-17, and qemu).

Ending the “silent drop”: how Dynamic Path MTU Discovery makes the Cloudflare One Client more resilient

Post Syndicated from Koko Uko original https://blog.cloudflare.com/client-dynamic-path-mtu-discovery/

You’ve likely seen this support ticket countless times: a user’s Internet connection that worked just fine a moment ago for Slack and DNS lookups is suddenly hung the moment they attempt a large file upload, join a video call, or initiate an SSH session. The culprit isn’t usually a bandwidth shortage or service outage issue, it is the “PMTUD Black Hole” — a frustration that occurs when packets are too large for a specific network path, but the network fails to communicate that limit back to the sender. This situation often happens when you’re locked into using networks you do not manage or vendors with maximum transmission unit (MTU) restrictions, and you have no means to address the problem.

Today, we are moving past these legacy networking constraints. By implementing Path MTU Discovery (PMTUD), the Cloudflare One Client has shifted from a passive observer to an active participant in path discovery.

Dynamic Path MTU Discovery allows the client to intelligently and dynamically adjust to the optimal packet size for most network paths using MTUs above 1281 bytes. This ensures that a user’s connection remains stable, whether they are on a high-speed corporate backbone or a restrictive cellular network.

The “modern security meets legacy infrastructure” challenge 

To understand the solution, we have to look at how modern security protocols interact with the diversity of global Internet infrastructure. The MTU represents the largest data packet size a device can send over a network without fragmentation: typically 1500 bytes for standard Ethernet.

As the Cloudflare One client has evolved to support modern enterprise-grade requirements (such as FIPS 140-2 compliance), the amount of metadata and encryption overhead within each packet has naturally increased. This is a deliberate choice to ensure our users have the highest level of protection available today.

However, much of the world’s Internet infrastructure was built decades ago with a rigid expectation of 1500-byte packets. On specialized networks like LTE/5G, satellite links, or public safety networks like FirstNet, the actual available space for data is often lower than the standard. When a secure, encrypted packet hits an older router with a lower limit (e.g., 1300 bytes), that router should ideally send an Internet Control Message Protocol (ICMP) message stating “Destination Unreachable” back to the sender to request a smaller size.

But that doesn’t always happen. The “Black Hole” occurs when firewalls or middleboxes silently drop those ICMP feedback messages. Without this feedback, the sender keeps trying to send large packets that never arrive, and the application simply waits in a “zombie” state until the connection eventually times out.


Cloudflare’s solution: active probing with PMTUD

Cloudflare’s implementation of RFC 8899 Datagram Packetization Layer Path MTU Discovery (PMTUD) removes the reliance on these fragile, legacy feedback loops. Because our modern client utilizes the MASQUE protocol — built on top of Cloudflare’s open source QUIC library — the client can perform active, end-to-end interrogation of the network path.

Instead of waiting for an error message that might never come, the client proactively sends encrypted packets of varying sizes to the Cloudflare edge. This probe tests MTUs from the upper bound of the supported MTU range to the midpoint, until the client narrows down to the exact MTU to match. This is a sophisticated, non-disruptive handshake happening in the background. If the Cloudflare edge receives a specific-sized probe, it acknowledges it; if a probe is lost, the client instantly knows the precise capacity of that specific network segment.

The client then dynamically resizes its virtual interface MTU on the fly, by periodically validating the capacity of the path that we established at connection onset. This ensures that if, for example, a user moves from a 1500-MTU Wi-Fi network at a station to a 1300-MTU cellular backhaul in the field, the transition is seamless. The application session remains uninterrupted because the client has already negotiated the best possible path for those secure packets.


Real-world impact, from first responders to hybrid workers

This technical shift has profound implications for mission-critical connectivity. Consider the reliability needs of a first responder using a vehicle-mounted router. These systems often navigate complex NAT-traversal and priority-routing layers that aggressively shrink the available MTU. Without PMTUD, critical software like Computer Aided Dispatch (CAD) systems may experience frequent disconnects during tower handoffs or signal fluctuations. By using active discovery, the Cloudflare One Client maintains a sticky connection that shields the application from the underlying network volatility.

This same logic applies to the global hybrid workforce. A road warrior working from a hotel in a different country often encounters legacy middleboxes and complex double-NAT environments. Instead of choppy video calls and stalled file transfers, the client identifies the bottleneck in seconds and optimizes the packet flow — before the user even notices a change.

Get PMTUD for your devices

Anyone using the Cloudflare One Client with the MASQUE protocol can try Path MTU Discovery now for free. Use our detailed documentation to get started routing traffic through the Cloudflare edge with the speed and stability of PMTUD on your Windows, macOS, and Linux devices.

If you are new to Cloudflare One, you too can start protecting your first 50 users for free. Simply create an account, download the Cloudflare One Client, and follow our onboarding guide to experience a faster, more stable connection for your entire team.

На позорния стълб

Post Syndicated from Светла Енчева original https://www.toest.bg/na-pozorniya-stulb/

На позорния стълб

Три минути. Толкова е времето между гласуванията на първо и второ четене на законопроект, приет с пълно мнозинство от 186 депутати от всички парламентарни групи (плюс четирима независими), присъстващи на заседанието на Народното събрание на 19 февруари 2026 г. Без дискусии, без експертни становища, без оценка на въздействието. Гласуването на първо четене е в 10:51, а на второ – съответно в 10:54.

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

Става въпрос за Закона за закрила на детето (ЗЗД). Конкретно – за т.нар. регистър на педофилите, приет през лятото на 2023 г. по предложение на „Възраждане“. Отново „Възраждане“ инициира и гласуваното на 19 февруари изменение. С него част от регистъра става публична. По-специално, „три имена на извършителя, дата на раждане, постоянен и настоящ адрес, вид престъпление и размер на наказанието“, а за чужденците се включват и „данните за държавите по произход“.

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

Не консенсус, а поддаване на натиск

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

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

Наистина ли им пука за децата?
Светла Енчева с паралел между два нашумели случая, в които са намесени деца. В единия ги намесиха от „голяма загриженост“, но без реална нужда, институциите и политиците, а в другия пак институциите и политиците си затварят очите за истинския проблем – насилие над малко дете от учителката му.
На позорния стълб

За сравнение, нека отново припомним, че кметът на Поморие Иван Алексиев (от ГЕРБ) публично защити учителка в детска градина в Каблешково срещу обвиненията, че е посегнала на 4-годишно момиченце. Подозрението за сексуално насилие в случая се крепи не само на думите на детето, а и на медицински свидетелства, установяващи болезнени издевателства и дори разкъсан химен. Наличието им е било известно на Алексиев към момента, в който защитава учителката. Това обаче не стана повод ГЕРБ да се асоциира с педофилията.

Под привидното единство при гласуването на промените в ЗЗД се открояват три вида парламентарни групи.

Първите („Възраждане“, ИТН и ДПС – Ново начало) активно призовават „регистърът на педофилите“ да стане публичен. Вторите (ПП–ДБ) се снишават, защото и без това без вина вече са обвинени в педофилия. Третите (останалите) са пасивни наблюдатели – било защото са печеливши от ситуацията (основно ГЕРБ), било за да не се набутват между точно тези токсични шамари.

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

За разлика от Хрисимиров, Тошко Йорданов (ИТН), който взема думата още преди депутатът от „Възраждане“ да е представил законопроекта, е неудържим. Той многократно използва думи, производни от „педофилия“, а следните словосъчетания – по няколко пъти: „педофилска секта“ (три пъти, два от които в съчетание с „петроханската“) и „ламата педофил“ (три пъти). В този словесен коктейл Йорданов 12 пъти споменава абревиатурата НПО в негативен контекст (едно от споменаванията гласи „педофилското НПО“), а ПП–ДБ, в същия контекст – 6 пъти. Без да броим споменаването на множество настоящи и бивши представители на коалицията и политици, асоциирани с нея.

И Хамид Хамид от ДПС – Ново начало споменава „педофилски НПО-та“. За разлика от Тошко Йорданов, който обвинява хора, организации и партии в прав текст, Хамид прави намеци като „има парламентарни групи, които се хвърлят на амбразурата да защитават педофилските прояви“. Когато заявява: „Макар и служебно, педофилите проникнаха в правителството на Република България“, председателката на Народното събрание Рая Назарян го съветва да се въздържа „от подобни квалификации“.

Ден по-рано впрочем, на 18 февруари, Хамид предложи възрастта на съгласие, която според Наказателния кодекс е 14 години, да се вдигне на 16 – отново без оценка на въздействието. Това беше прието, засега само на първо четене. Ако мине и на второ, 18-годишните, които са в сексуална връзка с 15-годишни, вече ще са престъпници и ще могат да влязат в „регистъра на педофилите“.

Възможни последствия от публичния регистър

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

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

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

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

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

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

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

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

Педофилията, срещу която се протестира, и педофилията, за която се мълчи
Гражданският гняв, изразяващ се в протести срещу насилието над деца и срещу неработещата държава, е абсолютно оправдан. Но е важно, когато си отваряме очите за едно, да не ги затваряме за друго. От Светла Енчева.
На позорния стълб

Ако не публичен регистър, то какво?

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

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

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

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

В България обаче акцентът пада върху тежестта на наказанията, а не върху превенцията. Ако някой има сексуална склонност към деца, той или тя може да не е в състояние да я преодолее, но е възможно да се научи да я контролира, ако получи съответната подкрепа. И в резултат на това да не злоупотребява с деца. Както един алкохолик не престава да бъде такъв, но може да спре да пие.

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

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

Работата с родителите е също много важна с оглед на превенцията. Защото някои от тях отказват да повярват, че детето им е било сексуално насилвано, особено ако извършителят е познат на семейството и то има доверие в него. Да не говорим, че има родители, които знаят, но си затварят очите. Особено ако извършителят е другият родител (кръвен или доведен) или техен интимен партньор.

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

За какво говорим, когато говорим за педофилия?

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

Първо, дали е склонност, или постъпка? Според Световната здравна организация (СЗО) е влечение. В едно демократично общество човек не може да бъде осъден единствено защото има някаква склонност – престъпление е само ако направиш нещо (или не направиш, а е трябвало).

Второ, на каква възраст трябва да е едно дете, за да става дума за педофилия? Според СЗО педофилията е влечение към деца в предпубертетна или ранна пубертетна възраст. В българския Наказателен кодекс думата „педофилия“ не се споменава, но са забранени сексуалните контакти с деца под 14-годишна възраст. Над 14 са разрешени, освен при определени случаи, например когато тийнейджърите са в зависима позиция спрямо извършителя. Регистърът на случаите на педофилия обаче включва извършителите на сексуални престъпления срещу лица до 18 години. В широк смисъл думата се използва за сексуални контакти с лица, ненавършили възрастта за съгласие, независимо каква е тя.

Трето, трябва ли да има някаква възрастова разлика между извършителя и детето, за да можем да говорим за педофилия? Според здравия разум – да, според българското законодателство – не. Ако 18-годишно момче е правило секс с 13-годишно момиче, защото момичето го е излъгало, че е на 16, момчето може да бъде осъдено. И да влезе в регистъра на педофилите.

50-годишен човек обаче, който е във връзка с 14-годишно дете по взаимно съгласие, няма да влезе в регистъра. В Германия например възрастта за съгласие е също 14 години, но човек, имащ сексуални отношения с тийнейджър между 14 и 16 години, трябва да е най-много на 21. В България, вместо да се помисли за въвеждане на подобна възрастова разлика, директно се върви към увеличаване на възрастта за съгласие. За да се създадат „служебно“ още повече престъпници и да има с какво да се пълни регистърът.

Но може би целта е да нямаме общо споделено разбиране за педофилията, а да я възприемаме като аморфно плашило.

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

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

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

В крайна сметка „Възраждане“, които също се борят за политическото си оцеляване на фона на новия политически проект на Румен Радев, победиха без бой. За трети път, след като през 2023 г. предложиха „регистъра на педофилите“ и той беше приет, а година по-късно инициираха промените в Закона за предучилищното и училищното образование, с които беше забранено говоренето по теми, свързани с ЛГБТИ. А ПП–ДБ, колкото и да се снишават, са в губеща позиция.

Британците казват, че любопитството убива котката. Може да добавим, че популизмът убива политиката. 

Теодор Караколев: Човек може да влияе силно, макар и върху малък кръг хора

Post Syndicated from Ина Иванова original https://www.toest.bg/teodor-karakolev-chovek-mozhe-da-vliyae-silno-makar-i-vurhu-maluk-krug-hora/

Теодор Караколев: Човек може да влияе силно, макар и върху малък кръг хора

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

Теодор Караколев е сред най-разпознаваемите изследователи на българската архитектура между двете световни войни и съосновател на Фондация „Български архитектурен модернизъм“. Фондацията изследва образци на архитектурата и изкуството в периода между 20-те и 40-те години на миналия век, организира изложби и лекции, поддържа една от най-големите онлайн общности, интересуващи се от архитектурно наследство.

Журналист и лектор в множество инициативи, включително и архитектурни обиколки, с деликатното си академично присъствие Тео Караколев предлага мултидисциплинарен подход. Не просто да архивира, а да напомня, че сме част от процес, от непрекъсната трансформация на търсенията и контекста – това е мисията на „Български архитектурен модернизъм“.

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

Никой не си прави илюзията, че градовете ни не са опърпани, недобре поддържани, „но не са безвъзвратно грозни“, настоява Тео Караколев.

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

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

Освен изследователско ровене из архиви и общински документи, работата на Васил Макаринов (за съжаление, напуснал ни твърде рано) и Теодор Караколев е да проследяват историята на множество малки сгради, да идентифицират архитекти, да анализират стилови особености. Те систематично документират и описват десетки малки обществени сгради, училища, читалища и къщи на заможни семейства в градове като Пловдив, Варна, Бургас, Стара Загора, Ямбол, Казанлък.

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

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

Историята на изкуството и историята на архитектурата са свързани, разделението, което съществува в България, го няма на други места. Това, което ние се опитваме да правим, е изкуствоведски поглед към архитектурата.

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

Така че аз харесвам определен тип творци, а не течения. Предпочитам такива, които не са толкова разказвателни и директни в посланието си.

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

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

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

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

В годините, в които се е налагало да чете задължителна литература в училище, Тео Караколев си е спестявал колкото може от програмата, за да освободи пространство за собствените си интереси. Днес не го нарича бунтарство, но се съгласява да го определим като независимост. Това е времето, в което открива Гогол и Достоевски.

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

И преди, и сега архитектурата бива използвана за политически битки.

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

Ето например филмът от 1920 г. „Кабинетът на доктор Калигари“, който е интерпретиран като предсказване за идването на Хитлер заради сляпото доверие, хипнозите, сомнамбулизма. Но не е ли твърде лесно да се намери тази връзка, когато събитието вече се е случило? Всяко произведение от този период показва несигурността, алтернативните търсения, несъзнаваното.

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

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

Чисто исторически има периоди на концентрация на история. В България в годините малко преди влизането в Европейския съюз досега сякаш имаше някакъв що-годе консенсус какво правим и накъде се движим. Сега сме в друг момент. Но отвъд злободневното аз мисля, че конкретният човек може да влияе силно, макар и върху малък кръг хора. И това е гражданското общество – съществуването на голям брой хора, които са активни. Ако обществото е здраво, то ще намери реакция срещу тоталитарните държави. Може би затова Германия успява да се възроди след Хитлер. Въпреки травмата.

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

Теодор Караколев открива собствения си път. И днес, докато се разхожда в Стария град на Пловдив или по тепетата, в кварталите и край реката, обича понякога да е сам.

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

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


Хората, които тихо и кротко променят средата, формират общности и задават посоки, в които има смисъл да тръгнем заедно. Тук ви срещаме с тях. Това са „Тези хора“.

The collective thoughts of the interwebz