Tag Archives: апи

How Castle is Building Codeless Customer Account Protection

Post Syndicated from Guest Author original https://blog.cloudflare.com/castle-building-codeless-customer-account-protection/

How Castle is Building Codeless Customer Account Protection

How Castle is Building Codeless Customer Account Protection

This is a guest post by Johanna Larsson, of Castle, who designed and built the Castle Cloudflare app and the supporting infrastructure.

Strong security should be easy.

Asking your consumers again and again to take responsibility for their security through robust passwords and other security measures doesn’t work. The responsibility of security needs to shift from end users to the companies who serve them.

Castle is leading the way for companies to better protect their online accounts with millions of consumers being protected every day. Uniquely, Castle extends threat prevention and protection for both pre and post login ensuring you can keep friction low but security high. With realtime responses and automated workflows for account recovery, overwhelmed security teams are given a hand. However, when you’re that busy, sometimes deploying new solutions takes more time than you have. Reducing time to deployment was a priority so Castle turned to Cloudflare Workers.

User security and friction

When security is no longer optional and threats are not black or white, security teams are left with trying to determine how to allow end-user access and transaction completions when there are hints of risk, or when not all of the information is available. Keeping friction low is important to customer experience. Castle helps organizations be more dynamic and proactive by making continuous security decisions based on realtime risk and trust.

Some of the challenges with traditional solutions is that they are often just focused on protecting the app or they are only focused on point of access, protecting against bot access for example. Tools specifically designed for securing user accounts however are fundamentally focused on protecting the accounts of the end-users, whether they are being targeting by human or bots. Being able to understand end-user behaviors and their devices both pre and post login is therefore critical in being able to truly protect each users. The key to protecting users is being able to decipher between normal and anomalous activity on an individual account and device basis. You also need a playbook to respond to anomalies and attacks with dedicated flows, that allows your end users to interact directly and provide feedback around security events.

By understanding the end user and their good behaviors, devices, and transactions, it is possible to automatically respond to account threats in real-time based on risk level and policy. This approach not only reduces end-user friction but enables security teams to feel more confident that they won’t ever be blocking a legitimate login or transaction.

Castle processes tens of millions of events every day through its APIs, including contextual information like headers, IP, and device types. The more information that can be associated with a request the better. This allows us to better recognize abnormalities and protect the end user. Collection of this information is done in two ways. One is done on the web application’s backend side through our SDKs and the other is done on the client side using our mobile SDK or browser script. Our experience shows that any integration of a security service based on user behavior and anomaly detection can involve many different parties across an organization, and it affects multiple layers of the tech stack. On top of the security related roles, it’s not unusual to also have to coordinate between backend, devops, and frontend teams. The information related to an end user session is often spread widely over a code base.

The cost of security

One of the biggest challenges in implementing a user-facing security and risk management solution is the variety of people and teams it needs attention from, each with competing priorities. Security teams are often understaffed and overwhelmed making it difficult to take on new projects. At the same time, it consumes time from product and engineering personnel on the application side, who are responsible for UX flows and performing continuous authentication post-login.

We’ve been experimenting with approaches where we can extract that complexity from your application code base, while also reducing the effort of integrating. At Castle, we believe that strong security should be easy.

How Castle is Building Codeless Customer Account Protection

With Cloudflare we found a service that enables us to create a more friendly, simple, and in the end, safe integration process by placing the security layer directly between the end user and your application. Security-related logic shouldn’t pollute your app, but should reside in a separate service, or shield, that covers your app. When the two environments are kept separate, this reduces the time and cost of implementing complex systems making integration and maintenance less stressful and much easier.

Our integration with Cloudflare aims to solve this implementation challenge, delivering end-to-end account protection for your users, both pre and post login, with the click of a button.

The codeless integration

In our quest for a purely codeless integration, key features are required. When every customer application is different, this means every integration is different. We want to solve this problem for you once and for all. To do this, we needed to move the security work away from the implementation details so that we could instead focus on describing the key interactions with the end user, like logins or bank transactions. We also wanted to empower key decision makers to recognize and handle crucial interactions in their systems. Creating a single solution that could be customized to fit each specific use case was a priority.

Building on top of Cloudflare’s platform, we made use of three unique and powerful products: Workers, Apps for Workers, and Workers KV.

Thanks to Workers we have full access to the interactions between the end user and your application. With their impressive performance, we can confidently run inline of website requests without creating noticeable latency. We will never slow down your site. And in order to achieve the flexibility required to match your specific use case, we created an internal configuration format that fully describes the interactions of devices and servers across HTTP, including web and mobile app traffic. It is in this Worker where we’ve implemented an advanced routing engine to match and collect information about requests and responses to events, directly from the edge. It also fully handles injecting the Castle browser script — one less thing to worry about.

All of this logic is kept separate from your application code, and through the Cloudflare App Store we are able to distribute this Worker, giving you control over when and where it is enabled, as well as what configurations are used. There’s no need to copy/paste code or manage your own Workers.

In order to achieve the required speed while running in distributed edge locations, we needed a high performing low latency datastore, and we found one in the Cloudflare Workers KV Store. Cloudflare Apps are not able to access the KV Store directly, but we’ve solved this by exposing it through a separate Worker that the Castle App connects to. Because traffic between Workers never leaves the Cloudflare network, this is both secure and fast enough to match your requirements. The KV Store allows us to maintain end user sessions across the world, and also gives us a place to store and update the configurations and sessions that drive the Castle App.

In combining these products we have a complete and codeless integration that is fully configurable and that won’t slow you down.

How does it work?

The data flow is straightforward. After installing the Castle App, Cloudflare will route your traffic through the Castle App, which uses the Castle Data Store and our API to intelligently protect your end users. The impact to traffic latency is minimal because most work is done in the background, not blocking the requests. Let’s dig deeper into each technical feature:

Script injection

One of the tools we use to verify user identity is a browser script: Castle.js. It is responsible for gathering device information and UI interaction behavior, and although it is not required for our service to function, it helps improve our verdicts. This means it’s important that it is properly added to every page in your web application. The Castle App, running between the end user and your application, is able to unobtrusively add the script to each page as it is served. In order for the script to also track page interactions it needs to be able to connect them to your users, which is done through a call to our script and also works out of the box with the Cloudflare interaction. This removes 100% of the integration work from your frontend teams.

Collect contextual information

The second half of the information that forms the basis of our security analysis is the information related to the request itself, such as IP and headers, as well as timestamps. Gathering this information may seem straightforward, but our experience shows some recurring problems in traditional integrations. IP-addresses are easily lost behind reverse proxies, as they need to be maintained as separate headers, like `X-Forwarded-For`, and the internal format of headers differs from platform to platform. Headers in general might get cut off based on whitelisting. The Castle App sees the original request as it comes in, with no outside influence or platform differences, enabling it to reliably create the context of the request. This saves your infrastructure and backend engineers from huge efforts debugging edge cases.

Advanced routing engine

Finally, in order to reliably recognize important events, like login attempts, we’ve built a fully configurable routing engine. This is fast enough to run inline of your web application, and supports near real-time configuration updates. It is powerful enough to translate requests to actual events in your system, like logins, purchases, profile updates or transactions. Using information from the request, it is then able to send this information to Castle, where you are able to analyze, verify and take action on suspicious activity. What’s even better, is that at any point in the future if you want to Castle protect a new critical user event – such as a withdrawal or transfer event – all it takes is adding a record to the configuration file. You never have to touch application code in order to expand your Castle integration across sensitive events.

We’ve put together an example TypeScript snippet that naively implements the flow and features we’ve discussed. The details are glossed over so that we can focus on the functionality.

addEventListener(event => event.respondWith(handleEvent(event)));

const respondWith = async (event: CloudflareEvent) => {
  // You configure the application with your Castle API key
  const { apiKey } = INSTALL_OPTIONS;
  const { request } = event;

  // Configuration is fetched from the KV Store
  const configuration = await getConfiguration(apiKey);

  // The session is also retrieved from the KV Store
  const session = await getUserSession(request);

  // Pass the request through and get the response
  let response = await fetch(request);

  // Using the configuration we can recognize events by running
  // the request+response and configuration through our matching engine
  const securityEvent = getMatchingEvent(request, response, configuration);

  if (securityEvent) {
    // With direct access to the raw request, we can confidently build the context
    // including a device ID generated by the browser script, IP, and headers
    const requestContext = getRequestContext(request);

    // Collecting the relevant information, the data is passed to the Castle API
    event.waitUntil(sendToCastle(securityEvent, session, requestContext));

  // Because we have access to the response HTML page we can safely inject the browser
  // script. If the response is not an HTML page it is passed through untouched.
  response = injectScript(response, session);

  return response;

We hope we have inspired you and demonstrated how Workers can provide speed and flexibility when implementing end to end account protection for your end users with Castle. If you are curious about our service, learn more here.

Top Resources for API Architects and Developers

Post Syndicated from George Mao original https://aws.amazon.com/blogs/architecture/top-resources-for-api-architects-and-developers/

We hope you’ve enjoyed reading our series on API architecture and development. We wrote about best practices for REST APIs with Amazon API Gateway  and GraphQL APIs with AWS AppSync. This post will cover the top resources that all API developers should be aware of.

Tech Talks, Webinars, and Twitch Live Stream

The technical staff at AWS have produced a variety of digital media that cover new service launches, best practices, and customer questions. Be sure to review these videos for tips and tricks on building APIs:

  • Happy Little APIs: This is a multi part series produced by our awesome Developer Advocate, Eric Johnson. He leads a series of talks that demonstrate how to build a real world API.
  • API Gateway’s WebSocket webinar: API Gateway now supports real time APIs with Websockets. This webinar covers how to use this feature and why you should let API Gateway manage your realtime APIs.
  • Best practices for building enterprise grade APIs: API Gateway reduces the time it takes to build and deploy REST development but there are strategies that can make development, security, and management easier.
  • An Intro to AWS AppSync and GraphQL: AppSync helps you build sophisticated data applications with realtime and offline capabilities.

Gain Experience With Hands-On Workshops and Examples

One of the easiest ways to get started with Serverless REST API development is to use the Serverless Application Model (SAM). SAM lets you run APIs and Lambda functions locally on your machine for easy development and testing.

For example, you can configure API Gateway as an Event source for Lambda with just a few lines of code:

Type: Api
Path: /photos
Method: post

There are many great examples on our GitHub page to help you get started with Authorization (IAMCognito), Request, Response,  various policies , and CORS configurations for API Gateway.

If you’re working with GraphQL, you should review the Amplify Framework. This is an official AWS project that helps you quickly build Web Applications with built in AuthN and backend APIs using REST or GraphQL. With just a few lines of code, you can have Amplify add all required configurations for your GraphQL API. You have two options to integrate your application with an AppSync API:

  1. Directly using the Amplify GraphQL Client
  2. Using the AWS AppSync SDK

An excellent walk through of the Amplify toolkit is available here, including an example showing how to create a single page web app using ReactJS powered by an AppSync GraphQL API.

Finally, if you are interested in a full hands on experience, take a look at:

  • The Amazon API Gateway WildRydes workshop. This workshop teaches you how to build a functional single page web app with a REST backend, powered by API Gateway.
  • The AWS AppSync GraphQL Photo Workshop. This workshop teaches you how to use Amplify to quickly build a Photo sharing web app, powered by AppSync.

Useful Documentation

The official AWS documentation is the source of truth for architects and developers. Get started with the API Gateway developer guide. API Gateway is currently has two APIs (V1 and V2) for managing the service. Here is where you can view the SDK and CLI reference.

Get started with the AppSync developer guide, and review the AppSync management API.


As an API architect, your job is not only to design and implement the best API for your use case, but your job is also to figure out which type of API is most cost effective for your product. For example, an application with high request volume (“chatty“) may benefit from a GraphQL implementation instead of REST.

API Gateway currently charges $3.50 / million requests and provides a free tier of 1 Million requests per month. There is tiered pricing that will reduce your costs as request volume rises. AppSync currently charges $4.00 / million for Query and Mutation requests.

While AppSync pricing per request is slightly higher, keep in mind that the nature of GraphQL APIs typically result in significantly fewer overall request numbers.

Finally, we encourage you to join us in the coming weeks — we will be starting a series of posts covering messaging best practices.

About the Author

George MaoGeorge Mao is a Specialist Solutions Architect at Amazon Web Services, focused on the Serverless platform. George is responsible for helping customers design and operate Serverless applications using services like Lambda, API Gateway, Cognito, and DynamoDB. He is a regular speaker at AWS Summits, re:Invent, and various tech events. George is a software engineer and enjoys contributing to open source projects, delivering technical presentations at technology events, and working with customers to design their applications in the Cloud. George holds a Bachelor of Computer Science and Masters of IT from Virginia Tech.

Announcing the General Availability of API Tokens

Post Syndicated from Garrett Galow original https://blog.cloudflare.com/api-tokens-general-availability/

Announcing the General Availability of API Tokens

APIs at Cloudflare

Announcing the General Availability of API Tokens

Today we are announcing the general availability of API Tokens – a scalable and more secure way to interact with the Cloudflare API. As part of making a better internet, Cloudflare strives to simplify manageability of a customer’s presence at the edge. Part of the way we do this is by ensuring that all of our products and services are configurable by API. Customers ranging from partners to enterprises to developers want to automate management of Cloudflare. Sometimes that is done via our API directly, and other times it is done via open source software we help maintain like our Terraform provider or Cloudflare-Go library. It is critical that customers who are automating management of Cloudflare can keep their Cloudflare services as secure as possible.

Least Privilege and Why it Matters

Securing software systems is hard. Limiting what a piece of software can do is a good defense to prevent mistakes or malicious actions from having greater impact than they could. The principle of least privilege helps guide how much access a given system should have to perform actions. Originally formulated by Jerome Saltzer, “Every program and every privileged user of the system should operate using the least amount of privilege necessary to complete the job.” In the case of Cloudflare, many customers have various domains routing traffic leveraging many different services. If a bad actor gets unauthorized access to a system they can use whatever access that system has to cause further damage or steal additional information.

Let’s see how the capabilities of API Tokens fit into the principle of least privilege.

About API Tokens

API Tokens provide three main capabilities:

  1. Scoping API Tokens by Cloudflare resource
  2. Scoping API Tokens by permission
  3. The ability to provision multiple API Tokens

Let’s break down each of these capabilities.

Scoping API Tokens by Cloudflare Resource

Cloudflare separates service configuration by zone which typically equates to a domain. Additionally, some customers have multiple accounts each with many zones. It is important that when granting API access to a service it only has access to the accounts resources and zones that are pertinent for the job at hand. API Tokens can be scoped to only cover specific accounts and specific zones. One common use case is if you have a staging zone and a production zone, then an API Token can be limited to only be able to affect the staging zone and not have access to the production zone.

Scoping API Tokens by Permission

Being able to scope an API Token to a specific zone is great, but in one zone there are many different services that can be configured: firewall rules, page rules, and load balancers just to name a few. If a customer has a service that should only be able to create new firewall rules in response to traffic patterns, then also allowing that service to change DNS records is a violation of least privilege. API Tokens allow you to scope each token to specific permission. Multiple permissions can be combined to create custom tokens to fit specific use cases.

Multiple API Tokens

If you use Cloudflare to protect and accelerate multiple services, then may be making API changes to Cloudflare from multiple locations – different servers, VMs, containers, or workers. Being able to create an API Token per service means each service is insulated to changes from another. If one API Token is leaked or needs to be rolled, there won’t be any impact to the other services’ API Tokens. Also the capabilities mentioned previously mean that each service can be scoped to exactly what actions and resources necessary. This allows customers to better realize the practice of least privilege for accessing Cloudflare by API.

Now let’s walk through how to create an API Token and use it.

Using API Tokens

To create your first API Token go to the ‘API Tokens’ section of your user profile which can be found here: dash.cloudflare.com/profile/api-tokens

1. On this page, you will find both a list of all of your API Tokens in addition to your Global API Key and Origin CA Key.

Announcing the General Availability of API Tokens
API Tokens Getting Started – Create Token

To create your first API Token, select ‘Create Token’.

2. On the create screen there are two ways to create your token. You can create it from scratch through the ‘Custom’ option or you can start with a predefined template by selecting ‘Start with a template’.

Announcing the General Availability of API Tokens
API Token Template Selection

For this case, we will use the ‘Edit zone DNS’ template to create an API Token that can edit a single zone’s DNS records.

3. Once the template is selected, we need to pick a zone for the API Token to be scoped to. Notice that the DNS Edit permission was already pre-selected.

Announcing the General Availability of API Tokens
Specifying the zone for which the token will be able to control DNS

In this case, ‘garrettgalow.com’ is selected as the Cloudflare zone that the API Token will be able to edit DNS records for.

4. Once I select continue to summary, I’m given a chance to review my selection. In this case the resources and permissions are quite simple, but this gives you a change to make sure you are giving the API Token exactly the correct amount of privilege before creating it.

Announcing the General Availability of API Tokens
Token Summary – confirmation

5. Once created, we are presented with the API Token. This screen is the only time you will be presented with the secret so be sure to put the secret in a safe place! Anyone with this secret can perform the granted actions on the resources specified so protect it like a password. In the below screenshot I have black boxed the secret for obvious reasons. If you happen to lose the secret, you can always regenerate it from the API Tokens table so you don’t have to configure all the permissions again.

Announcing the General Availability of API Tokens
Token creation completion screen with the token secret

In addition to the secret itself this screen provides an example curl request that can be used to verify that the token was successfully created. It also provides an example of how the token should be used for any direct HTTP requests. With API Tokens we now follow the RFC Authorization Bearer standard. Calling that API we see a successful response telling us that the token is valid and active

~$ curl -X GET "https://api.cloudflare.com/client/v4/user/tokens/verify" \
>      -H "Authorization: Bearer vh9awGupxxxxxxxxxxxxxxxxxxx" \
>      -H "Content-Type:application/json" | jq

  "result": {
    "id": "ad599f2b67cdccf24a160f5dcd7bc57b",
    "status": "active"
  "success": true,
  "errors": [],
  "messages": [
      "code": 10000,
      "message": "This API Token is valid and active",
      "type": null

What’s coming next

For anyone using the Cloudflare API, we recommend moving to using API Tokens over their predecessor API Keys going forward. With this announcement, our Terraform provider, Cloudflare-Go library, and WordPress plugin are all updated for API Token compatibility. Other libraries will receive updates soon. Both API Tokens and API Keys will be supported for the time being for customers to be able to safely migrate. We have more planned capabilities for API Tokens to further safeguard how and when tokens are used, so stay tuned for future announcements!

Let us know what you think and what you’d like to see next regarding API security on the Cloudflare Community.

Things to Consider When You Build a GraphQL API with AWS AppSync

Post Syndicated from Steve Johnson original https://aws.amazon.com/blogs/architecture/things-to-consider-when-you-build-a-graphql-api-with-aws-appsync/

Co-authored by George Mao

When building a serverless API layer in AWS (one that provides a custom grammar for your serverless resources), your choices include Amazon API Gateway (REST) and AWS AppSync (GraphQL). We’ve discussed the differences between REST and GraphQL in our first post of this series and explored REST APIs in our second post. This post will dive deeper into GraphQL implementation with AppSync.

Note that the GraphQL specification is focused on grammar and expected behavior, and is light on implementation details. Therefore, each GraphQL implementation approaches these details in a different way. While this blog post speaks to architectural principles, it will also discuss specific features AppSync for practical advice.

Schema vs. Resolver Complexity

All GraphQL APIs are defined by their schema. The schema contains operation definitions (Queries, Mutations, and Subscriptions), as well as data definitions (Data and Input Types). Since GraphQL tools provide introspection, your Schema also becomes your API documentation. So, as your Schema grows, it’s important that it’s consistent and adheres to best practices (such as the use of Input Types for mutations).

Clients will love using your API if they can do what they want with as little work as possible. A good rule of thumb is to put any necessary complexity in the resolver rather than in the client code. For example, if you know client applications will need “Book” information that includes the cover art and current sales ranking – all from different data sources – you can build a single data type that combines them:

GraphQL API -1

In this case, the complexity associated with assembling that data should be handled in the resolver, rather than forcing the client code to make multiple calls and manipulate the returned data.

Mapping data storage to schema gets more complex when you are accessing legacy data services: internal APIs, external REST services, relational database SQL, and services with custom protocols or libraries. The other end of the spectrum is new development, where some architects argue they can map their entire schema to a single source. In practice, your mapping should consider the following:

  • Should slower data sources have a caching layer?
  • Do your most frequently used operations have low latency?
  • How many layers (services) does a request touch?
  • Can high latency requests be modeled asynchronously?

With AppSync, you have the option to use Pipeline Resolvers, which execute reusable functions within a resolver context. Each function in the pipeline can call one of the native resolver types.


Public APIs (ones with an external endpoint) provide access to secured resources. The first line of defense is authorization – restricting who can call an operation in the GraphQL Schema. AppSync has four methods to authenticate clients:

  • API keys: Since the API key does not reference an identity and is easily compromised, we recommend it be used for development only.
  • IAMs: These are standard AWS credentials that are often used for server-side processes. A common example is assigning an execution role to a AWS Lambda function that makes calls to AppSync.
  • OIDC Tokens: These are time-limited and suitable for external clients.
  • Cognito User Pool Tokens: These provide the advantages of OIDC tokens, and also allow you to use the @auth transform for authorization.

Authorization in GraphQL is handled in the resolver logic, which allows field-level access to your data, depending on any criteria you can express in the resolver. This allows flexibility, but also introduces complexity in the form of code.

AppSync Resolvers use a Request/Response template pattern similar to API Gateway. Like API Gateway, the template language is Apache Velocity. In an AppSync resolver, you have the ability to examine the incoming authentication information (such as the IAM username) in the context variable. You can then compare that username against an owner field in the data being retrieved.

AppSync provides declarative security using the @auth and @model transforms. Transforms are annotations you add to your schema that are interpreted by the Amplify Toolchain. Using the @auth transform, you can apply different authentication types to different operations. AppSync will automatically generate resolver logic for DynamoDB, based on the data types in your schema. You can also define field-level permissions based on identity. Get detailed information.


To get a quantitative view of your API’s performance, you should enable field-level logging on your AppSync API. Doing so will automatically emit information into CloudWatch Logs. Then you can analyze AppSync performance with CloudWatch Logs Insights to identify performance bottlenecks and the root cause of operational problems, such as:

  • Resolvers with the maximum latency
  • The most (or least) frequently invoked resolvers
  • Resolvers with the most errors

Remember, choice of resolver type has an impact on performance. When accessing your data sources, you should prefer a native resolver type such as Amazon DynamoDB or Amazon ElasticSearch using VTL templates. The HTTP resolver type is very efficient, but latency depends on the performance of the downstream service. Lambda resolvers provide flexibility, but have the performance characteristics of your application code.

AppSync also has another resolver type, the Local Resolver, which doesn’t interact with a data source. Instead, this resolver invokes a mutation operation that will result in a subscription message being sent. This is useful in use cases where AppSync is used as a message bus, or in cases where the data has been modified by an external source, and notifications must be sent without modifying the data a second time.

GraphQL API -2

GraphQL Subscriptions

One of the reasons customers choose GraphQL is the power of Subscriptions. These are notifications that are sent immediately to clients when data has changed by a mutation. AppSync subscriptions are implemented using Websockets, and are directly tied to a mutation in the schema. The AppSync SDKs and AWS Amplify Library allow clients to subscribe to these real-time notifications.

AppSync Subscriptions have many uses outside standard API CRUD operations. They can be used for inter-client communication, such as a mobile or web chat application. Subscription notifications can also be used to provide asynchronous responses to long-running requests. The initial request returns quickly, while the full result can be sent via subscription when it’s complete (local resolvers are useful for this pattern).

Subscriptions will only be received if the client is currently running, connected to the server, and is subscribed to the target mutation. If you have a mobile client, you may want to augment these notifications with mobile or web push notifications.


The choice of using a GraphQL API brings many advantages, especially for client developers. While basic considerations of Security and Performance are important (as they are in any solution), GraphQL APIs require some thought and planning around Schema and Resolver organization, and managing their complexity.

About the author

Steve Johnson

Steve Johnson is a Specialist Solutions Architect at Amazon Web Services, focused on Mobile Applications. Steve helps customers design Mobile and GraphQL applications using AWS Amplify, Amazon AppSync, Amazon Cognito, and the AWS Serverless Suite of products. He is a speaker at AWS Summits and various tech events. Steve is a software and systems engineer and enjoys tinkering with all things mechanical and cloud related. He holds a Bachelor of Mechanical Engineering and Masters in Software Systems Engineering. Steve lives and works near us-east-1, because the latency is good.


Scaling Kubernetes deployments with Amazon CloudWatch metrics

Post Syndicated from Ignacio Riesgo original https://aws.amazon.com/blogs/compute/scaling-kubernetes-deployments-with-amazon-cloudwatch-metrics/

This post is contributed by Kwunhok Chan | Solutions Architect, AWS


In an earlier post, AWS introduced Horizontal Pod Autoscaler and Kubernetes Metrics Server support for Amazon Elastic Kubernetes Service. These tools make it easy to scale your Kubernetes workloads managed by EKS in response to built-in metrics like CPU and memory.

However, one common use case for applications running on EKS is the integration with AWS services. For example, you administer an application that processes messages published to an Amazon SQS queue. You want the application to scale according to the number of messages in that queue. The Amazon CloudWatch Metrics Adapter for Kubernetes (k8s-cloudwatch-adapter) helps.


Amazon CloudWatch Metrics Adapter for Kubernetes

The k8s-cloudwatch-adapter is an implementation of the Kubernetes Custom Metrics API and External Metrics API with integration for CloudWatch metrics. It allows you to scale your Kubernetes deployment using the Horizontal Pod Autoscaler (HPA) with CloudWatch metrics.



Before starting, you need the following:


Getting started

Before using the k8s-cloudwatch-adapter, set up a way to manage IAM credentials to Kubernetes pods. The CloudWatch Metrics Adapter requires the following permissions to access metric data from CloudWatch:


Create an IAM policy with the following template:

    "Version": "2012-10-17",
    "Statement": [
            "Effect": "Allow",
            "Action": [
            "Resource": "*"

For demo purposes, I’m granting admin permissions to my Kubernetes worker nodes. Don’t do this in your production environment. To associate IAM roles to your Kubernetes pods, you may want to look at kube2iam or kiam.

If you’re using an EKS cluster, you most likely provisioned it with AWS CloudFormation. The following command uses AWS CloudFormation stacks to update the proper instance policy with the correct permissions:

aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AdministratorAccess \
--role-name $(aws cloudformation describe-stacks --stack-name ${STACK_NAME} --query 'Stacks[0].Parameters[?ParameterKey==`NodeInstanceRoleName`].ParameterValue' | jq -r ".[0]")


Make sure to replace ${STACK_NAME} with the nodegroup stack name from the AWS CloudFormation console .


You can now deploy the k8s-cloudwatch-adapter to your Kubernetes cluster.

$ kubectl apply -f https://raw.githubusercontent.com/awslabs/k8s-cloudwatch-adapter/master/deploy/adapter.yaml


This deployment creates a new namespace—custom-metrics—and deploys the necessary ClusterRole, Service Account, and Role Binding values, along with the deployment of the adapter. Use the created custom resource definition (CRD) to define the configuration for the external metrics to retrieve from CloudWatch. The adapter reads the configuration defined in ExternalMetric CRDs and loads its external metrics. That allows you to use HPA to autoscale your Kubernetes pods.


Verifying the deployment

Next, query the metrics APIs to see if the adapter is deployed correctly. Run the following command:

$ kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1" | jq.
  "kind": "APIResourceList",
  "apiVersion": "v1",
  "groupVersion": "external.metrics.k8s.io/v1beta1",
  "resources": [

There are no resources from the response because you haven’t registered any metric resources yet.


Deploying an Amazon SQS application

Next, deploy a sample SQS application to test out k8s-cloudwatch-adapter. The SQS producer and consumer are provided, together with the YAML files for deploying the consumer, metric configuration, and HPA.

Both the producer and consumer use an SQS queue named helloworld. If it doesn’t exist already, the producer creates this queue.

Deploy the consumer with the following command:

$ kubectl apply -f https://raw.githubusercontent.com/awslabs/k8s-cloudwatch-adapter/master/samples/sqs/deploy/consumer-deployment.yaml


You can verify that the consumer is running with the following command:

$ kubectl get deploy sqs-consumer
sqs-consumer   1         1         1            0           5s


Set up Amazon CloudWatch metric and HPA

Next, create an ExternalMetric resource for the CloudWatch metric. Take note of the Kind value for this resource. This CRD resource tells the adapter how to retrieve metric data from CloudWatch.

You define the query parameters used to retrieve the ApproximateNumberOfMessagesVisible for an SQS queue named helloworld. For details about how metric data queries work, see CloudWatch GetMetricData API.

apiVersion: metrics.aws/v1alpha1
kind: ExternalMetric:
    name: hello-queue-length
    name: hello-queue-length
      resource: "deployment"
        - id: sqs_helloworld
              namespace: "AWS/SQS"
              metricName: "ApproximateNumberOfMessagesVisible"
                - name: QueueName
                  value: "helloworld"
            period: 300
            stat: Average
            unit: Count
          returnData: true


Create the ExternalMetric resource:

$ kubectl apply -f https://raw.githubusercontent.com/awslabs/k8s-cloudwatch-adapter/master/samples/sqs/deploy/externalmetric.yaml


Then, set up the HPA for your consumer. Here is the configuration to use:

kind: HorizontalPodAutoscaler
apiVersion: autoscaling/v2beta1
  name: sqs-consumer-scaler
    apiVersion: apps/v1beta1
    kind: Deployment
    name: sqs-consumer
  minReplicas: 1
  maxReplicas: 10
  - type: External
      metricName: hello-queue-length
      targetValue: 30


This HPA rule starts scaling out when the number of messages visible in your SQS queue exceeds 30, and scales in when there are fewer than 30 messages in the queue.

Create the HPA resource:

$ kubectl apply -f https://raw.githubusercontent.com/awslabs/k8s-cloudwatch-adapter/master/samples/sqs/deploy/hpa.yaml


Generate load using a producer

Finally, you can start generating messages to the queue:

$ kubectl apply -f https://raw.githubusercontent.com/awslabs/k8s-cloudwatch-adapter/master/samples/sqs/deploy/producer-deployment.yaml

On a separate terminal, you can now watch your HPA retrieving the queue length and start scaling the replicas. SQS metrics generate at five-minute intervals, so give the process a few minutes:

$ kubectl get hpa sqs-consumer-scaler -w


Clean up

After you complete this experiment, you can delete the Kubernetes deployment and respective resources.

Run the following commands to remove the consumer, external metric, HPA, and SQS queue:

$ kubectl delete deploy sqs-producer
$ kubectl delete hpa sqs-consumer-scaler
$ kubectl delete externalmetric sqs-helloworld-length
$ kubectl delete deploy sqs-consumer

$ aws sqs delete-queue helloworld


Other CloudWatch integrations

AWS recently announced the preview for Amazon CloudWatch Container Insights, which monitors, isolates, and diagnoses containerized applications running on EKS and Kubernetes clusters. To get started, see Using Container Insights.


Get involved

This project is currently under development. AWS welcomes issues and pull requests, and would love to hear your feedback.

How could this adapter be best implemented to work in your environment? Visit the Amazon CloudWatch Metrics Adapter for Kubernetes project on GitHub and let AWS know what you think.

Announcing the New Cloudflare Partner Platform

Post Syndicated from Garrett Galow original https://blog.cloudflare.com/announcing-the-new-cloudflare-partner-platform/

Announcing the New Cloudflare Partner Platform

Announcing the New Cloudflare Partner Platform

When I first started at Cloudflare over two years ago, one of the first things I was tasked with was to help evolve our partner platform to support the changes in our service and the expanding needs of our partners and customers. Cloudflare’s existing partner platform was released in 2010. It is a testament to those who built it, that it was, and still is, in use today—but it was also clear that the landscape had substantially changed.

Since the launch of the existing partner platform, we had built and expanded multi-user access, and launched many new products: Argo, Load Balancing, and Cloudflare Workers, to name a few. Retrofitting the existing offering was not practical. Cloudflare needed a new partner platform that could meet the needs of partners and their customers.

As the team started to develop a new solution, we needed to find a partner who could keep us on the right path. The number of hypotheticals were infinite and we needed a first customer to ground ourselves. Lo and behold, not long after I had begun putting pen to paper, we found the perfect partner for the new platform.

The IBM Partnership

IBM was looking for a partner to bring various edge services to market quickly, and our suite of capabilities was what they were looking for. If you are not familiar with our partnership with IBM, you can learn a bit more about it in our blog post and on the IBM Cloud Internet Services landing page. We signed the contract in November 2017, and we had to be ready to launch by IBM Think the following February. Given that IBM’s engineering team needed time to integrate with us, we were on a tight timeline to deliver.

A number of team members and I jumped on a plane and flew to Austin, Texas (Hook ‘em!) to work with IBM and determine the minimum viable product (MVP). Over kolaches (for the Czech readers at home: Klobásník), IBM and Cloudflare nailed down the MVP requirements. Briefly, they were as follows:

  1. Full API integration to provision the building blocks of using Cloudflare.
    • This included:
      1. Accounts: The container of resources – typically zones
      2. Users: The way in which we partition access to accounts
  2. The ability to sell and provision Cloudflare’s paid services and package them in a way that made sense for IBM’s customers.
    • Our existing partner platform only supported zone plans and none of our newer offerings, such as Argo or load balancing.
    • IBM had specific requirements around how they could package and sell to customers, so our solution needed to be flexible enough to support that.
  3. Ensure that what we built was re-usable.
    • Cloudflare makes it a point to solve problems for scale. While we were focused on ensuring our first partner would be successful, we knew that long term we would need to be able to scale this solution to additional partners. Nothing we built could prevent us from doing that.

Over the next couple of months, many teams at Cloudflare came together to deliver this solution at breakneck speed. Given that the midpoint of this effort happened over the holiday season, I’m personally proud of our company not sacrificing employee’s time with their friends and families in order to deliver. Even when it feels like a sprint, it is still a marathon.

During this time, the engineering team we were working with at IBM felt like another team at Cloudflare. Their ability to move quickly, integrate, and validate our work was critical to the success of the project. At THINK in February 2018, we were able to announce the Beta of IBM CIS (Cloud Internet Services) powered by Cloudflare!

Following the initial release, we continued to add functionality to further enrich the IBM CIS offering, while behind the scenes we continued our work to redefine Cloudflare’s partner platform.

The New Partner Platform

Over the past year we have expanded the capabilities and completed the necessary work to enable more partners to be able to use what we initially built for the IBM partnership. Out of that comes our new partner platform we are announcing today. The new partner platform allows partners of Cloudflare to sell and provision Cloudflare for their customers in a scalable fashion.

Our new partner platform is the combination of two systems designed to fulfill specific needs:

1. Tenants: an abstraction on top of our existing accounts and users for easier management
2. Subscriptions: a new way of packaging and provisioning services


An absolute necessity for partners is the ability to provision accounts for each of their customers. Normally the only way to get a Cloudflare account is to sign up on the dashboard. We needed a way for partners to be able to create end customer accounts at their discretion to support their specific onboarding needs. This also ensures proper separation of ownership between customers and allows end customers to access the Cloudflare dashboard directly.

With the introduction of tenants, our data model now looks like the following:

Announcing the New Cloudflare Partner Platform
Cloudflare Resource Data Model

Tenants provide partners the ability to create and manage the accounts for their customers. Each account created is a separate container of resources (zones, workers, etc) for each of customer. Users can be invited to each account as necessary for self service management, while the partner retains control of the capabilities enabled for each account. How a partner manages those capabilities brings us to the second major system that makes up the new partner platform.


While not as obvious as the need for account provisioning, the ability to package and provision services is critical to providing differentiated offerings for partners of Cloudflare. One drawback of our old partner platform was the difficulty in ensuring new products and services were available to those partners. As Cloudflare grew, it reached the point where new paid services could not be added into the existing partner platform.

With subscriptions, this is no longer the case. What started as just a way to provision services for IBM, has now grown into the standard of how all customer services are provisioned at Cloudflare. Whether you purchase services through IBM CIS or buy Cloudflare Workers in our dashboard, behind the scenes, Subscriptions is what ensures you get exactly the right services enabled.

Enough talk, let’s show things in action!

The Partner Platform in Action

The full details of using the new partner platform can be found in our Provisioning API docs, but here we provide a walkthrough of a typical use case.

Using the new partner platform involves 4 steps:

  1. Provisioning Customer Accounts
  2. Granting Customer Access
  3. Enabling Services
  4. Service Configuration

1) Provisioning Customer Accounts

When onboarding customers, you want each to have their own Cloudflare account. This ensures one customer can not affect any resources belonging to another. By making a `POST /accounts` request, you can create an account for an individual customer.


curl -X POST \
    https://api.cloudflare.com/client/v4/accounts \
    -H 'Content-Type: application/json' \
    -H 'x-auth-email: <x-auth-email>' \
    -H 'x-auth-key: <x-auth-key>' \
    -d '{ "name": "Customer Account", 
          "type": "standard" 


    "result": {
        "id": "2bab6ace8c72ed3f09b9eca6db1396bb",
        "name": "Customer Account",
        "type": "standard",
        "settings": {
            "enforce_twofactor": false
    "success": true,
    "errors": [],
    "messages": []

This new account is owned by the partner. It can be managed by API, or in the UI by the partner or any additional administrators that are invited.

2) Granting Customer Access

Now that the customer’s account is created, let’s give them access to it. This step uses existing APIs and if you have shared access to a Cloudflare account before, then you have already done this.


curl -X POST \
    'https://api.cloudflare.com/client/v4/accounts/2bab6ace8c72ed3f09b9eca6db1396bb/members' \
    -H 'Content-Type: application/json' \
    -H 'x-auth-email: <x-auth-email>' \
    -H 'x-auth-key: <x-auth-key>' \
    -d '{ "email": "[email protected]",
          "roles": ["05784afa30c1afe1440e79d9351c7430"],
          "status": "accepted" 


    "result": {
        "id": "47bd8083af8516a20c410090d2f53655",
        "user": {
            "id": "fccad3c46f26dc2d6ba47ad19f639707",
            "first_name": null,
            "last_name": null,
            "email": "[email protected]",
            "two_factor_authentication_enabled": false
        "status": "pending",
        "roles": [
                "id": "05784afa30c1afe1440e79d9351c7430",
                "name": "Administrator",
                "description": "Can access the full account, except for membership management and billing.",
                "permissions": {
                    "organization": {
                        "read": true,
                        "edit": true
                    "zone": {
                        "read": true,
                        "edit": true
    "success": true,
    "errors": [],
    "messages": []

Alternatively, you can do this in the UI, from the Members section for the newly created account.

3) Enabling Services

Now the fun part! With the ability to provision subscriptions, you can enable paid services for your customers. Before we do that though, we will create a zone so we can attach a zone subscription to it.

Adding a zone as a partner is no different than adding a zone as a regular customer. It can also be done by the customer.


curl -X POST \
    https://api.cloudflare.com/client/v4/zones \
    -H 'Content-Type: application/json' \
    -H 'x-auth-email: <x-auth-email>' \
    -H 'x-auth-key: <x-auth-key>' \
    -d '{ "name": "theircompany.com",
            "account": { "id": "2bab6ace8c72ed3f09b9eca6db1396bb" }


    "result": {
        "id": "cae181e41197e2eb875d9bcb9396abe7",
        "name": "theircompany.com",
        "status": "pending",
        "paused": false,
        "type": "full",
        "development_mode": 0,
        "name_servers": [
        "original_name_servers": null,
        "original_registrar": "cloudflare, inc.",
        "original_dnshost": null,
        "modified_on": "2019-05-30T17:51:08.510558Z",
        "created_on": "2019-05-30T17:51:08.510558Z",
        "activated_on": null,
        "meta": {
            "step": 4,
            "wildcard_proxiable": false,
            "custom_certificate_quota": 0,
            "page_rule_quota": 3,
            "phishing_detected": false,
            "multiple_railguns_allowed": false
        "owner": {
            "id": null,
            "type": "user",
            "email": null
        "account": {
            "id": "2bab6ace8c72ed3f09b9eca6db1396bb",
            "name": "Customer Account"
        "permissions": [
        "plan": {
            "id": "0feeeeeeeeeeeeeeeeeeeeeeeeeeeeee",
            "name": "Free Website",
            "price": 0,
            "currency": "USD",
            "frequency": "",
            "is_subscribed": true,
            "can_subscribe": false,
            "legacy_id": "free",
            "legacy_discount": false,
            "externally_managed": false
    "success": true,
    "errors": [],
    "messages": []

For this customer we will provision a Pro plan for the newly created zone. If you are not familiar with our zone plans, then you can read about them here. For this, we make a call to the subscriptions service.


curl -X POST \
    https://api.cloudflare.com/client/v4/zones/cae181e41197e2eb875d9bcb9396abe7/subscription \
  -H 'Content-Type: application/json' \
  -H 'X-Auth-Email: <x-auth-email>' \
  -H 'X-Auth-Key: <x-auth-key>' \
  -d '{"rate_plan": {
          "id": "PARTNERS_PRO"}


    "success": true,
    "result": {
        "id": "ff563a93e11c46e7b278be46f49cdd2f",
        "product": {
            "name": "partners_cloudflare_zones",
            "period": "",
            "billing": "",
            "public_name": "CloudFlare Services",
            "duration": 0
        "rate_plan": {
            "id": "partners_pro",
            "public_name": "Partners Professional Plan",
            "currency": "USD",
            "scope": "zone",
            "externally_managed": false,
            "sets": [
            "is_contract": true
        "component_values": [
                "name": "dedicated_certificates",
                "value": 0,
                "price": 0
                "name": "dedicated_certificates_custom",
                "value": 0,
                "price": 0
                "name": "page_rules",
                "value": 20,
                "default": 20,
                "price": 0
                "name": "zones",
                "value": 1,
                "default": 1,
                "price": 0
        "zone": {
            "id": "cae181e41197e2eb875d9bcb9396abe7",
            "name": "theircompany.com"
        "frequency": "monthly",
        "currency": "USD",
        "app": {
            "install_id": null
        "entitled": true
    "messages": null,
    "api_version": "2.0.0"

Now that the customer is set up with an account, zone, and zone subscription, the only thing left is configuring the resources appropriately.

4) Service Configuration

Service configuration can be done by either you, the partner, or the end customer. Most commonly, DNS records need to be added, security settings verified and updated, and customizations made. These can all be done either through our Client v4 APIs or the Cloudflare Dashboard.

Once that is done, the customer is all set!

This is just the beginning

With our announcement today, partners can protect and accelerate their customer’s internet services with Cloudflare’s partner platform. We have battled tested the underlying systems over the last year and are excited to partner with others to help make a better internet. We are not done yet though. We will be continually investing in the tenant and subscription services to expand their capabilities and simplify usage.

Announcing the New Cloudflare Partner Platform
Some of the latest partners using the new partner platform

If you are interested in partnering with Cloudflare, then reach out to [email protected]. If building the future of how Cloudflare’s partners and customers use our service sounds interesting then take a look at our career page.

For more information, see the following resources:

Android Rx onError Guidelines

Post Syndicated from Netflix Technology Blog original https://medium.com/netflix-techblog/android-rx-onerror-guidelines-e68e8dc7383f?source=rss----2615bd06b42e---4

Rx onError Guidelines

By Ed Ballot

“Creating a good API is hard.” — anyone who has created an API used by others

As with any API, wrapping your data stream in a Rx observable requires consideration for reasonable error handling and intuitive behavior. The following guidelines are intended to help developers create consistent and intuitive API.

Since we frequently create Rx Observables in our Android app, we needed a common understanding of when to use onNext() and when to use onError() to make the API more consistent for subscribers. The divergent understanding is partially because the name “onError” is a bit misleading. The item emitted by onError() is not a simple error, but a throwable that can cause significant damage if not caught. Our app has a global handler that prevents it from crashing outright, but an uncaught exception can still leave parts of the app in an unpredictable state.

TL;DR — Prefer onNext() and only use onError() for exceptional cases.

Considerations for onNext / onError

The following are points to consider when determining whether to use onNext() versus onError().

The Contract

First here are the definitions of the two from the ReactiveX contract page:

conveys an item that is emitted by the Observable to the observer

indicates that the Observable has terminated with a specified error condition and that it will be emitting no further items

As pointed out in the above definition, a subscription is automatically disposed after onError(), just like after onComplete(). Because of this, onError() should only be used to signal a fatal error and never to signal an intermittent problem where more data is expected to stream through the subscription after the error.

Treat it like an Exception

Limit using onError() for exceptional circumstances when you’d also consider throwing an Error or Exception. The reasoning is that the onError() parameter is a Throwable. An example for differentiating: a database query returning zero results is typically not an exception. The database returning zero results because it was forcibly closed (or otherwise put in a state that cancels the running query) would be an exceptional condition.

Be Consistent

Do not make your observable emit a mix of both deterministic and non-deterministic errors. Something is deterministic if the same input always result in the same output, such as dividing by 0 will fail every time. Something is non-deterministic if the same inputs may result in different outputs, such as a network request which may timeout or may return results before the timeout. Rx has convenience methods built around error handling, such as retry() (and our retryWithBackoff()). The primary use of retry() is to automatically re-subscribe an observable that has non-deterministic errors. When an observable mixes the two types of errors, it makes retrying less obvious since retrying a deterministic failures doesn’t make sense — or is wasteful since the retry is guaranteed to fail. (Two notes: 1. retry can also be used in certain deterministic cases like user login attempts, where the failure is caused by incorrectly entering credentials. 2. For mixed errors, retryWhen() could be used to only retry the non-deterministic errors.) If you find your observable needs to emit both types of errors, consider whether there is an appropriate separation of concerns. It may be that the observable can be split into several observables that each have a more targeted purpose.

Be Consistent with Underlying APIs

When wrapping an asynchronous API in Rx, consider maintaining consistency with the underlying API’s error handling. For example, if you are wrapping a touch event system that treats moving off the device’s touchscreen as an exception and terminates the touch session, then it may make sense to emit that error via onError(). On the other hand, if it treats moving off the touchscreen as a data event and allows the user to drag their finger back onto the screen, it makes sense to emit it via onNext().

Avoid Business Logic

Related to the previous point. Avoid adding business logic that interprets the data and converts it into errors. The code that the observable is wrapping should have the appropriate logic to perform these conversions. In the rare case that it does not, consider adding an abstraction layer that encapsulates this logic (for both normal and error cases) rather than building it into the observable.

Passing Details in onError()

If your code is going to use onError(), remember that the throwable it emits should include appropriate data for the subscriber to understand what went wrong and how to handle it.

For example, our Falcor response handler uses a FalcorError class that includes the Status from the callback. Repositories could also throw an extension of this class, if extra details need to be included.

Android Rx onError Guidelines was originally published in Netflix TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Eating Dogfood at Scale: How We Build Serverless Apps with Workers

Post Syndicated from Jonathan Spies original https://blog.cloudflare.com/building-serverless-apps-with-workers/

Eating Dogfood at Scale: How We Build Serverless Apps with Workers

Eating Dogfood at Scale: How We Build Serverless Apps with Workers

You’ve had a chance to build a Cloudflare Worker. You’ve tried KV Storage and have a great use case for your Worker. You’ve even demonstrated the usefulness to your product or organization. Now you need to go from writing a single file in the Cloudflare Dashboard UI Editor to source controlled code with multiple environments deployed using your favorite CI tool.

Fortunately, we have a powerful and flexible API for managing your workers. You can customize your deployment to your heart’s content. Our blog has already featured many things made possible by that API:

These tools make deployments easier to configure, but it still takes time to manage. The Serverless Framework Cloudflare Workers plugin removes that deployment overhead so you can spend more time working on your application and less on your deployment.

Focus on your application

Here at Cloudflare, we’ve been working to rebuild our Access product to run entirely on Workers. The move will allow Access to take advantage of the resiliency, performance, and flexibility of Workers. We’ll publish a more detailed post about that migration once complete, but the experience required that we retool some of our process to match or existing development experience as much as possible.

To us this meant:

  • Git
  • Easily deploy
  • Different environments
  • Unit Testing
  • CI Integration
  • Typescript/Multiple Files
  • Everything Must Be Automated

The Cloudflare Access team looked at three options for automating all of these tools in our pipeline. All of the options will work and could be right for you, but custom scripting can be a chore to maintain and Terraform lacked some extensibility.

  1. Custom Scripting
  2. Terraform
  3. Serverless Framework

We decided on the Serverless Framework. Serverless Framework provided a tool to mirror our existing process as closely as possible without too much DevOps overhead. Serverless is extremely simple and doesn’t interfere with the application code. You can get a project set up and deployed in seconds. It’s obviously less work than writing your own custom management scripts. But it also requires less boiler plate than Terraform because the Serverless Framework is designed for the “serverless” niche. However, if you are already using Terraform to manage other Cloudflare products, Terraform might be the best fit.


Everything for the project happens in a YAML file called serverless.yml. Let’s go through the features of the configuration file.

To get started, we need to install serverless from npm and generate a new project.

npm install serverless -g
serverless create --template cloudflare-workers --path myproject
cd myproject
npm install

If you are an enterprise client, you want to use the cloudflare-workers-enterprise template as it will set up more than one worker (but don’t worry, you can add more to any template). Also, I’ll touch on this later, but if you want to write your workers in Rust, use the cloudflare-workers-rust template.

You should now have a project that feels familiar, ready to be added to your favorite source control. In the project should be a serverless.yml file like the following.

    name: hello-world

  name: cloudflare

  - serverless-cloudflare-workers

    name: hello
    script: helloWorld  # there must be a file called helloWorld.js
      - http:
          url: example.com/hello/*
          method: GET
            foo: bar
            x-client-data: value

The service block simply contains the name of your service. This will be used in your Worker script names if you do not overwrite them.

Under provider, name must be ‘cloudflare’  and you need to add your account and zone IDs. You can find them in the Cloudflare Dashboard.

The plugins section adds the Cloudflare specific code.

Now for the good part: functions. Each block under functions is a Worker script.

name: (optional) If left blank it will be STAGE-service.name-script.identifier. If I removed name from this file and deployed in production stage, the script would be named production-hello-world-hello.

script: the relative path to the javascript file with the worker script. I like to organize mine in a folder called handlers.

events: Currently Workers only support http events. We call these routes. The example provided says that GET https://example.com/hello/<anything here> will  cause this worker to execute. The headers block is for testing invocations.

At this point you can deploy your worker!

[email protected] CLOUDFLARE_AUTH_KEY=XXXXXXXX serverless deploy

This is very easy to deploy, but it doesn’t address our requirements. Luckily, there’s just a few simple modifications to make.

Maturing our YAML File

Here’s a more complex YAML file.

  name: hello-world

    - node_modules/**
  excludeDevDependencies: false

  defaultStage: development
  deployVars: ${file(./config/deploy.${self:provider.stage}.yml)}

kv: &kv
  - variable: MYUSERS
    namespace: users

  name: cloudflare
  stage: ${opt:stage, self:custom.defaultStage}
    accountId: ${env:CLOUDFLARE_ACCOUNT_ID}
    zoneId: ${env:CLOUDFLARE_ZONE_ID}

  - serverless-cloudflare-workers

    name: ${self:provider.stage}-hello
    script: handlers/hello
    webpack: true
      MY_ENV_VAR: ${self:custom.deployVars.env_var_value}
      SENTRY_KEY: ${self:custom.deployVars.sentry_key}
      kv: *kv
      - http:
          url: "${self:custom.deployVars.SUBDOMAIN}.mydomain.com/hello"
          method: GET
      - http:
          url: "${self:custom.deployVars.SUBDOMAIN}.mydomain.com/alsohello*"
          method: GET

We can add a custom section where we can put custom variables to use later in the file.

defaultStage: We set this to development so that forgetting to pass a stage doesn’t trigger a production deploy. Combined with the stage option under provider we can set the stage for deployment.

deployVars: We use this custom variable to load another YAML file dependent on the stage. This lets us have different values for different stages. In development, this line loads the file ./config/deploy.development.yml. Here’s an example file:

env_var_value: true
sentry_key: XXXXX

kv: Here we are showing off a feature of YAML. If you assign a name to a block using the ‘&’, you can use it later as a YAML variable. This is very handy in a multi script account. We could have named this variable anything, but we are naming it kv since it holds our Workers Key Value storage settings to be used in our function below.

Inside of the kv block we’re creating a namespace and binding it to a variable available in your Worker. It will ensure that the namespace “users” exists and is bound to MYUSERS.

kv: &kv
  - variable: MYUSERS
    namespace: users

provider: The only new part of the provider block is stage.

stage: ${opt:stage, self:custom.defaultStage}

This line sets stage to either the command line option or custom.defaultStage if opt:stage is blank. When we deploy, we pass —stage=production to serverless deploy.

Now under our function we have added webpack, resources, and environment.

webpack: If set to true, will simply bundle each handler into a single file for deployment. It will also take a string representing a path to a webpack config file so you can customize it. This is how we add Typescript support to our projects.

resources: This block is used to automate resource creation. In resources we’re linking back to the kv block we created earlier.

Side note: If you would like to include WASM bindings in your project, it can be done in a very similar way to how we included Workers KV. For more information on WASM, see the documentation.

environment: This is the butter for the bread that is managing configuration for different stages. Here we can specify values to bind to variables to use in worker scripts. Combined with YAML magic, we can store our values in the aforementioned config files so that we deploy different values in different stages. With environments, we can easily tie into our CI tool. The CI tool has our deploy.production.yml. We simply run the following command from within our CI.

sls deploy --stage=production

Finally, I added a route to demonstrate that a script can be executed on multiple routes.

At this point I’ve covered (or hinted) at everything on our original list except Unit Testing. There are a few ways to do this.

We have a previous blog post about Unit Testing that covers using cloud worker, a great tool built by Dollar Shave Club.

My team opted to use the classic node frameworks mocha and sinon. Because we are using Typescript, we can build for node or build for v8. You can also make mocha work for non-typescript projects if you use an experimental feature that adds import/export support to node.


We’re excited about moving more and more of our services to Cloudflare Workers, and the Serverless Framework makes that easier to do. If you’d like to learn even more or get involved with the project, see us on github.com. For additional information on using Serverless Framework with Cloudflare Workers, check out our documentation on the Serverless Framework.

Announcing WebSocket APIs in Amazon API Gateway

Post Syndicated from Chris Munns original https://aws.amazon.com/blogs/compute/announcing-websocket-apis-in-amazon-api-gateway/

This post is courtesy of Diego Magalhaes, AWS Senior Solutions Architect – World Wide Public Sector-Canada & JT Thompson, AWS Principal Software Development Engineer – Amazon API Gateway

Starting today, you can build bidirectional communication applications using WebSocket APIs in Amazon API Gateway without having to provision and manage any servers.

HTTP-based APIs use a request/response model with a client sending a request to a service and the service responding synchronously back to the client. WebSocket-based APIs are bidirectional in nature. This means that a client can send messages to a service and services can independently send messages to its clients.

This bidirectional behavior allows for richer types of client/service interactions because services can push data to clients without a client needing to make an explicit request. WebSocket APIs are often used in real-time applications such as chat applications, collaboration platforms, multiplayer games, and financial trading platforms.

This post explains how to build a serverless, real-time chat application using WebSocket API and API Gateway.


Historically, building WebSocket APIs required setting up fleets of hosts that were responsible for managing the persistent connections that underlie the WebSocket protocol. Now, with API Gateway, this is no longer necessary. API Gateway handles the connections between the client and service. It lets you build your business logic using HTTP-based backends such as AWS Lambda, Amazon Kinesis, or any other HTTP endpoint.

Before you begin, here are a couple of the concepts of a WebSocket API in API Gateway. The first is a new resource type called a route. A route describes how API Gateway should handle a particular type of client request, and includes a routeKey parameter, a value that you provide to identify the route.

A WebSocket API is composed of one or more routes. To determine which route a particular inbound request should use, you provide a route selection expression. The expression is evaluated against an inbound request to produce a value that corresponds to one of your route’s routeKey values.

There are three special routeKey values that API Gateway allows you to use for a route:

  • $default—Used when the route selection expression produces a value that does not match any of the other route keys in your API routes. This can be used, for example, to implement a generic error handling mechanism.
  • $connect—The associated route is used when a client first connects to your WebSocket API.
  • $disconnect—The associated route is used when a client disconnects from your API. This call is made on a best-effort basis.

You are not required to provide routes for any of these special routeKey values.

Build a serverless, real-time chat application

To understand how you can use the new WebSocket API feature of API Gateway, I show you how to build a real-time chat app. To simplify things, assume that there is only a single chat room in this app. Here are the capabilities that the app includes:

  • Clients join the chat room as they connect to the WebSocket API.
  • The backend can send messages to specific users via a callback URL that is provided after the user is connected to the WebSocket API.
  • Users can send messages to the room.
  • Disconnected clients are removed from the chat room.

Here’s an overview of the real-time chat application:

A serverless real-time chat application using WebSocket API on Amazon API Gateway

The application is composed of the WebSocket API in API Gateway that handles the connectivity between the client and servers (1). Two AWS Lambda functions react when clients connect (2) or disconnect (5) from the API. The sendMessage function (3) is invoked when the clients send messages to the server. The server sends the message to all connected clients (4) using the new API Gateway Management API. To track each of the connected clients, use a DynamoDB table to persist the connection identifiers.

To help you see this in action more quickly, I’ve provided an AWS SAM application that includes the Lambda functions, DynamoDB table definition, and IAM roles. I placed it into the AWS Serverless Application Repository. For more information, see the simple-websockets-chat-app repo on GitHub.

Create a new WebSocket API

  1. In the API Gateway console, choose Create API, New API.
  2. Under Choose the protocol, choose WebSocket.
  3. For API name, enter My Chat API.
  4. For Route Selection Expression, enter $request.body.action.
  5. Enter a description if you’d like and click Create API.

The attribute described by the Route Selection Expression value should be present in every message that a client sends to the API. Here’s one example of a request message:

    "action": "sendmessage",
    “data”: "Hello, I am using WebSocket APIs in API Gateway.”

To route messages based on the message content, the WebSocket API expects JSON-formatted messages with a property serving as a routing key.

Manage routes

Now, configure your new API to respond to incoming requests. For this app, create three routes as described earlier. First, configure the sendmessage route with a Lambda integration.

  1. In the API Gateway console, under My Chat API, choose Routes.
  2. For New Route Key, enter sendmessage and confirm it.

Each route includes route-specific information such as its model schemas, as well as a reference to its target integration. With the sendmessage route created, use a Lambda function as an integration that is responsible for sending messages.

At this point, you’ve either deployed the AWS Serverless Application Repository backend or deployed it yourself using AWS SAM. In the Lambda console, look at the sendMessage function. This function receives the data sent by one of the clients, looks up all the currently connected clients, and sends the provided data to each of them. Here’s a snippet from the Lambda function:

DDB.scan(scanParams, function (err, data) {
  // some code omitted for brevity

  var apigwManagementApi = new AWS.APIGatewayManagementAPI({
    apiVersion: "2018-11-29",
    endpoint: event.requestContext.domainName " /" + event.requestContext.stage
  var postParams = {
    Data: JSON.parse(event.body).data

  data.Items.forEach(function (element) {
    postParams.ConnectionId = element.connectionId.S;
    apigwManagementApi.postToConnection(postParams, function (err, data) {
      // some code omitted for brevity

When one of the clients sends a message with an action of “sendmessage,” this function scans the DynamoDB table to find all of the currently connected clients. For each of them, it makes a postToConnection call with the provided data.

To send messages properly, you must know the API to which your clients are connected. This means explicitly setting the SDK endpoint to point to your API.

What’s left is to properly track the clients that are connected to the chat room. For this, take advantage of two of the special routeKey values and implement routes for $connect and $disconnect.

The onConnect function inserts the connectionId value from requestContext to the DynamoDB table.

exports.handler = function(event, context, callback) {
  var putParams = {
    TableName: process.env.TABLE_NAME,
    Item: {
      connectionId: { S: event.requestContext.connectionId }

  DDB.putItem(putParams, function(err, data) {
    callback(null, {
      statusCode: err ? 500 : 200,
      body: err ? "Failed to connect: " + JSON.stringify(err) : "Connected"

The onDisconnect function removes the record corresponding with the specified connectionId value.

exports.handler = function(event, context, callback) {
  var deleteParams = {
    TableName: process.env.TABLE_NAME,
    Key: {
      connectionId: { S: event.requestContext.connectionId }

  DDB.deleteItem(deleteParams, function(err) {
    callback(null, {
      statusCode: err ? 500 : 200,
      body: err ? "Failed to disconnect: " + JSON.stringify(err) : "Disconnected."

As I mentioned earlier, the onDisconnect function may not be called. To keep from retrying connections that are never going to be available again, add some additional logic in case the postToConnection call does not succeed:

if (err.statusCode === 410) {
  console.log("Found stale connection, deleting " + postParams.connectionId);
  DDB.deleteItem({ TableName: process.env.TABLE_NAME,
                   Key: { connectionId: { S: postParams.connectionId } } });
} else {
  console.log("Failed to post. Error: " + JSON.stringify(err));

API Gateway returns a status of 410 GONE when the connection is no longer available. If this happens, delete the identifier from the DynamoDB table.

To make calls to your connected clients, your application needs a new permission: “execute-api:ManageConnections”. This is handled for you in the AWS SAM template.

Deploy the WebSocket API

The next step is to deploy the WebSocket API. Because it’s the first time that you’re deploying the API, create a stage, such as “dev,” and give a sample description.

The Stage editor screen displays all the information for managing your WebSocket API, such as Settings, Logs/Tracing, Stage Variables, and Deployment History. Also, make sure that you check your limits and read more about API Gateway throttling.

Make sure that you monitor your tests using the dashboard available for your newly created WebSocket API.

Test the chat API

To test the WebSocket API, you can use wscat, an open-source, command line tool.

  1. Install NPM.
  2. Install wscat:
    $ npm install -g wscat
  3. On the console, connect to your published API endpoint by executing the following command:
    $ wscat -c wss://{YOUR-API-ID}.execute-api.{YOUR-REGION}.amazonaws.com/{STAGE}
  4. To test the sendMessage function, send a JSON message like the following example. The Lambda function sends it back using the callback URL:
    $ wscat -c wss://{YOUR-API-ID}.execute-api.{YOUR-REGION}.amazonaws.com/dev
    connected (press CTRL+C to quit)
    > {"action":"sendmessage", "data":"hello world"}
    < hello world

If you run wscat in multiple consoles, each will receive the “hello world”.

You’re now ready to send messages and get responses back and forth from your WebSocket API!


In this post, I showed you how to use WebSocket APIs in API Gateway, including a message exchange between client and server using routes and the route selection expression. You used Lambda and DynamoDB to create a serverless real-time chat application. While this post only scratched the surface of what is possible, you did all of this without needing to manage any servers at all.

You can get started today by creating your own WebSocket APIs in API Gateway. To learn more, see the Amazon API Gateway Developer Guide. You can also watch the Building Real-Time Applications using WebSocket APIs Supported by Amazon API Gateway webinar hosted by George Mao.

I’m excited to see what new applications come up with your use of the new WebSocket API. I welcome any feedback here, in the AWS forums, or on Twitter.

Happy coding!

За едно дарение

Post Syndicated from Bozho original https://blog.bozho.net/blog/3132

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

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

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

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

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

Даряване на софтуер за електронно управление вече се е случвало. Например в Естония. Там основни софтуерни компоненти са били дарени. Е, след това фирмите са получавали поръчки за надграждане и поддръжка (ние нямаме такова намерение). Но благодарение на това взаимодействие между държава и частен сектор, в Естония нещата „потръгват“. Нашето решение не е ключов компонент, така че едно дарение няма да доведе значителни промени и да настигнем Естония, но със сигурност ще бъде от помощ.

Като цяло реакцията на дарението беше позитивна, което е чудесно. Имаше и някои разумни притеснения и критики – например защо не отворим кода, като сме прокарали законово изменение за отворения код. Както неведнъж съм подчертавал, изискването важи само за софтуер, чиято разработка държавата поръчва и съответно става собственик. Случаят не е такъв, става дума за лицензи на готово решение. Но все пак всички компоненти (библиотеки и др.) около продукта са с отворен код и могат да се ползват свободно за интеграция.

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

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

ЕСПЧ: Най-лошото решение за 2017

Post Syndicated from nellyo original https://nellyo.wordpress.com/2018/06/02/echr-24/

Strasbourg Observers традиционно обявяват най-добро и най-лошо решение на ЕСПЧ всяка година.   За най-лошо решение от 2017 г. е обявено особеното мнение по делото Bayev v. Russia  относно закона за  анти-гей-пропагандата в Русия: “Хомофобският характер на несъгласието на съдията от Русия  относно така наречения гей пропаганден закон  беше толкова шокиращ  за нашите читатели, че спечели наградата за най-лошото решение, въпреки че технически не е самостоятелно решение, а само особено мнение”.

Това е добра причина да се представи решението на ЕСПЧ от 2017, така както е представено от Strasbourg Observers:

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

Жалбоподателите твърдят пред ЕСПЧ, че руското законодателство нарушава член 10 от ЕКПЧ и е дискриминационно, тъй като не се прилагат подобни ограничения по отношение на хетеросексуалното мнозинство.


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

ЕСПЧ не вижда причина социалното приемане на хомосексуалността да е несъвместимо с поддържането на семейни ценности. Както е посочено в решението по делото Kozak v Полша,  няма приет правилен начин за лицата да водят личния си семеен или личен живот.

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

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

Правителството не е доказало и как педофилията и порнографията сред малолетните и непълнолетните (независимо от сексуалната ориентация на засегнатите лица) са свързани с хомосексуалността и с този закон.

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

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


Ако настъпи война – 2: Съветите на Енота

Post Syndicated from Григор original http://www.gatchev.info/blog/?p=2143

Под предишния запис от темата можете да намерите няколко линка. Два са тежки за четене, но навеждат на някои мисли. Единият е разказ на преживял окупация по време на гражданската война в Югославия. Другият са съветите на бивш сътрудник на ГРУ (руското военно разузнаване), известен под прякора Енота, как да се оцелее при война.

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

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


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

При втория вариант ще се наложи да воювате, ако естествено искате. При третия можете и да не воювате вече. Родината я просрахме. Може „със смъртта на храбрите“, може и да продължите да живеете и работите, ако ви позволят.

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

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

Да-да, стрелбата и труповете още нищо не значат, колкото и да ви е странно. Ненавременната маневра „да се измитаме максимално далече“ може да ви струва живота. Не се суетете, не се паникьосвайте, вместо това внимателно се вгледайте КОЙ и ПО КОГО стреля, и най-важното – ЗАЩО.

Докато сме в града

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

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

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

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

Надали ще ви убиват специално. В мътни времена никой не хаби боеприпасите по хора без оръжие. Естествено, това не е повод да се разхождате и да си подсвирквате преди сън, но помнете – вие не сте цел No. 1. Опитът от град Грозни показва, че мъже, воюващи на пълни обороти, просто игнорират цивилните, не им е до тях. Наказание за глупост винаги можете да получите, особено по здрач, но нещата не са съвсем лоши.

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

Избягвайте да се мотаете и пред болници. И двете страни ще искат да си карат там ранените, сградата е стратегическа, нищо чудно да почнат сражение за нея – а то значи стрелба. Почне ли пък бомбардировка, някой задължително ще цапне болницата, изобщо не се съмнявайте. Тези, дето са писали Женевската конвенция, няма да ги има на бойното поле, така че спазването ѝ е леко условно. Като в „Карибски пирати“: „Това не е законодателство. По-скоро е набор пожелателни правила.“

Не забравяйте – почне ли такава каша, вече нямате собственост. И настоятелно ви съветвам да не проимвате. Убивате, ако някой се опитва да докопа храната и водата ви, всичко останало са дреболии. Ако сте успели да размените в най-близкия полицейски участък колата си срещу автомат, голямо браво. Ако ще да е чисто нов Мерцедес срещу старичък сгъваем калашник със само 2-3 пълнителя, пак голямо браво. Колата вече не ви трябва. Да излезете с нея от града няма да можете 100%, а пък желанието да я надупчат ще е сериозно.

Докато сте в града, избягвайте камуфлажни дрехи. По такива се стреля.

И така, в града ни са почнали улични боеве. Решили сме впредвид обстоятелствата или по тактически съображения да останем там (въпреки че идеята почти винаги е лоша). Знаем, че магазините ще почнат да ги грабят още на второто денонощие, оръжие има в най-близкия полицейски участък, малко вода има в казанчето на тоалетната (ако успеете да се сдобиете с бутилка-две минерална от някой магазин, още по-добре). Собственост вече нямате. Който е въоръжен, той е прав. Където има въоръжени, вас трябва да ви няма. Който се облича като военен – воюва, независимо дали иска. Тайник с гориво е голям плюс, горивото в някой момент може да стане на цената на оръжието и боеприпасите. Към важни обекти не си и помисляте да се приближавате.

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

Ако ще напускаме града

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

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

Важно: не се качвайте на превози! Какъвто и да е транспорт в града задължително ще бъде обстрелян.

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

Раницата я замятате с бял чаршаф и го закрепвате на нея стабилно. Прави се, ако ви види някой военен (а такива ще има много, не се и надявайте да се промъкнете незабелязани), да разбере че сте ЦИВИЛЕН и да не си издава позицията заради вас. Ще ви съпроводят в кръстачката на мерника, но ще ви оставят да продължите. Разбира се, не правете манифестация по централната улица, но и не се мажете с кал в стил Шварценегер – ще ви мярнат и отстрелят, понеже няма да знаят кой и какъв сте. Камуфлажа го зарежете, даже ако ви е единствените читави дрехи.

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

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

Питат ли за оръжие – казвате, че имате автомат (не вадите и не показвате, а казвате със спокоен глас), и молите да ви го оставят. Ще ви го вземат 100%, но това ще ви позволи да запазите пистолета. (За него не споменавайте – дадете ли автомата, надали ще ви тършуват.) Автомата ще го забележат винаги, а щом го давате спокойно и без съпротива, значи не сте буен. Един вид разменяте своите неща за свои. Ако нямате пистолет, взимате гладкостволка в разглобен вид, важното е да дадете „голямото и страшно“ оръжие. Изхождаме от допускането, че щом вече градът е обкръжен и са почнали улични боеве, трябва да не сте зяпали реклами по телевизията, а да сте напазарували вече в полицейския участък.

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

Стигнете ли до обкръжението или до заградителните кордони, изхвърляте пистолета и с високо вдигнати ръце и викане, че се предавате, размахвате белия чаршаф и вървите към войниците. При възможност гледайте да отивате не къде да е, а към пропускателен пункт или охранителен пост. Ако трябва, вървете половин километър към него с вдигнати ръце. Идеята е, че пунктовете и постовете са укрепени и често оборудвани за „прием“, войниците се чувстват там по-комфортно и шансовете да ви гръмнат са по-малки. Ще ви претръскат до дупка. Оръжието сте го изхвърлили предварително, кротичък гражданин сте. Ще ви привика офицер, вероятно лейтентант, надали по-старши, не е нужно да биете чело в земята. Намирате начин да говорите на четири очи с него и му предлагате ценности срещу право на преминаване. Мине ли всичко успешно, сте излезли от града.

По пътя с пълна сигурност ще изгубите почти всичко ценно и всичкото оръжие, и ще затриете за това смешно разстояние поне 1-2 дни. ТОВА Е НОРМАЛНО. Обкръжен град е огромен пленнически лагер. Давайте всичко, само за да излезете. Вътре ще почне глад, и то скоро.

И така, вървите внимателно, но не се криете като „разузнавачи“. Облечени сме цивилно, имаме бял парцал на гърба (отпред се вижда, че не носим оръжие, но откъм гърба – не, трябва да се застраховаме). Имаме малка торбичка с най-необходими благини. Имаме скъпоценности (злато) като валута. Оръжие, с което да не забравим да се разделим преди да стигнем до военния пост (намерят ли го у вас, трудно ще минете за цивилен – ще ви пишат или дезертьор, или преоблечен враг). Ако сте успели да излезете с тези неща от града за 1 до 3 дни, преминавайки от район в район, това е нормално.

От личния опит: обикновените фъстъчени сникерси са много хранителни. 6 двойни са дневната норма калории за мъж. Удобства за притопляне на храна надали ще имате. Сникерсите не са шведска маса, но по време на война не бъдете претенциозни към храната. Идеята със сникерсите, честно казано, е открадната от чеченците. Те на тях изкарват войната. Може да се яде в движение и е чудесна идея – захар, глюкоза, повдига настроението (ще ви е много нужно, понеже ще сте физически и психологически в дупка).

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

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

И така, най-лошият вариант: оказваме се извън града, но почти без храна и оръжие. В идеалния случай всеки от вас ще е огледал предварително (примерно сега) картата и ще е нахвърлил няколко места, където може да отстъпи. НИКАКВИ ГЕРОЙСТВА! Първо да се успокои ситуацията, после ще се оправяте къде какво става. Избирайте места според посоките на света. Прост пример: Санкт-Петербург. На запад надали ще е вариант да се отстъпва. На юг също няма смисъл. Ще бягате или на север, към Карелия, или на изток, към Новгородската и Тверската области. И от Москва най-вероятно ще са северното (Архангелск) и източното (Урал) направление.

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

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

Най-просто ми е да дам за пример Санкт Петербург. Я да видим картата. Във всяка посока трябва да имате набелязани ПОНЕ по две места, близко и далечно. За близкото препоръчвам някой туристически къмпинг, разположен до неголямо населено място. Ако сте били на излет край някое езеро или рекичка, на барбекю примерно, спокойно можете да идете там. Първо, ще знаете какво ви чака. Ще имате представа къде там има питейна вода и продоволствие. Второ, познавате мястото и това много ще ви крепи психологически.

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

И така, вече имаме две точки за отстъпление близо до града. Сега са ни нужни две далечни точки. Ако ще отстъпвате на север, бих ви предложил Соловецкия манастир, на остров в Бяло море. Има там едно селище на име Рабочеостровск, от него курсират кораби. Естествено, те няма вече да курсират, но винаги може да „приватизирате“ лодка с гребла на пристанището. Бяло море е сравнително спокойно. Да се преплава е реално (сложно е, но е възможно, от хленчене файда няма, така че гребем). На изток бих отстъпвал към Иверския манастир в Тверска област. Той също е на островче насред езеро. Наблизо има хранителни складове и производства (по трасе М10).

Защо манастири? Тях няма да ги бомбардират първи (това не значи, че после приоритетите няма да се променят). И още нещо: идеите за християнските добродетели ги забравете веднага. Нито ще ви чака там някой, нито ще ви се радва. Отивате там реално да се продавате в робство. Ще работите за тях, селскостопанска работа, или охранителна, или там каквото – те ще ви дават по нещичко за ядене. Стигнете ли, казвате им: „Силен и здрав мъж съм, ще работя каквото кажете срещу храна.“ Темата за морално-нравствената отговорност на поповете пред миряните я забравете веднага, и гък не гъквайте по въпроса.

Разбира се, всичко е условно. Може да изберете друго място. Главното е принципът: собствеността ви вече я няма, доволни сте да сте в полу-робство, ако ще ви хранят. Между другото, липсата на вашата собственост значи липса на собствеността и на другите. Който не може да защити имуществото си с оръжие, няма имущество.

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

Движете се бавно! 50-60 км в час, не повече. Може да налетите на военен конвой, ако карате бързо, ще ви опукат „за всеки случай“. Цивилни, които се опитват да ви спрат, не се котират, давайте газ. Те с вас няма да споделят своето, а да „споделят“ вашето ще се пробват. Конвой или дори отделно военно возило – спирате на банкета, отваряте леко прозорец или врата и показвате ръцете. Да излизате не е мъдро, поражда желание да ви преджобят. Седите спокойно, без нерви и се молите наум. Да ги пронизвате с поглед не се препоръчва – гледайте пред себе си или в пода.

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

А сега малко цинизъм. Ако имате „обоз“, демек семейство, сте покойник. Имате ли семейство, сте длъжни да се ометете от града и да цъфнете на вилата (със запаси от храна и вода) в първите секунди, когато на улицата почнат да псуват Великия Пу. Ако нямате къде да отстъпите с „обоза“ си, сте пълнеж за ковчези, и обозът ви също. Не тъпейте, подгответе се предварително, близките ТРЯБВА ДА ИМА КЪДЕ ДА ОТИДАТ. И трябва да имат продоволствие. После правете каквото щете. Ако щете, се връщайте и воювайте, ако щете се връщайте и висете по кръчмите, докато жена ви е „на картофите“. Но мислете за тях предварително, после ще бъде късно. Всичко по-горе е за самотници, дето нямат какво да губят. Имате ли семейство, се пригответе предварително. Историята учи, че семейството е по-скъпо от Родината, поне на първия етап.


Тези съвети (заедно с още – как да воювате и с какво да се снабдите, ако ще воювате) ги има на стотици места из руския Нет, поне от 2013 г. Често с дребни, но забележими разлики в текста. Същността обаче е една и съща.

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

Също, съветът с лодката и гребането до Соловецките острови ми се струва попресилен. От Рабочеостровск до Соловецк са нещо към 70-80 км по права линия. С гребна лодка, каквато може да бъде намерена на пристанище от сорта на това в Рабочеостровск, и световен шампион надали ще ги преодолее за 24 часа, а опитен, но неподготвен за състезание гребец – за 48 часа. Положението се подобрява малко, ако сте цяла лодка яки гребци, но пак трябва да сте сигурни, че ви чакат поне 24 часа екстра време – а прогнози за времето в Онежката губа вероятно тогава също няма да има.

Като цяло впечатлението ми за Енота от разказа му е за човек с опит от войната в Чечня, но и с известна доза художествено въображение.

И си мисля – дано никога и никой не се нуждае от тези съвети.

Което ме навежда на още мисли – но тях ще напиша следващия път.

Препоръка на ЕК за достъпа до научна информация

Post Syndicated from nellyo original https://nellyo.wordpress.com/2018/05/31/access-9/

Станаха известни новите изисквания за академично израстване, включително изискванията за научна продукция.  Но научната продукция е свързана и с условията за научно творчество, вкл. системна промяна към отворена  наука.

Публикувана е Препоръка (ЕС) 2018/790 на Комисията от 25 април 2018 година относно достъпа до научна информация и нейното съхранение

Държавите членки следва да гарантират, че:

  • тези диалози укрепват свързаната технологична среда за отворена наука, която обхваща всички резултати от всички етапи на жизнения цикъл на научните изследвания (данни, публикации, програмно осигуряване, методи, протоколи и т.н.);
  • постепенно се постига системна промяна към отворена наука, която освен технологичната промяна и ефикасността включва също така принципа на реципрочност, изменения в културата сред изследователите, както и институционална промяна във връзка с научните изследвания в академичните институции и финансиращите органи в посока към отворена наука, в това число въпроси като морал и етика, когато е приложимо.

Държавите  следва да информират Комисията в срок от 18 месеца от публикуването на настоящата препоръка в Официален вестник на Европейския съюз, а след това — веднъж на всеки две години, за действията, предприети в изпълнение на елементите, предвидени в настоящата препоръка. На тази база Комисията следва да извършва преглед на напредъка в рамките на Съюза, за да прецени дали е необходимо допълнително действие за постигане на целите, предложени в настоящата препоръка.

Швеция: „Ако настъпи криза или война“

Post Syndicated from Григор original http://www.gatchev.info/blog/?p=2141

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

Затова се постреснах мъничко, когато до (почти) всяко домакинство в Швеция беше доставена една специална брошура, озаглавена „Ако настъпи криза или война“. През 1947 г. Швеция наистина беше изготвила подобна брошура, и мине се не мине десетилетие през Студената война, я доставяше на домакинствата си. За последен път това се случи през 1990 г. Почти трийсет години беше история. Но сега я доставиха пак – в осъвременен вариант.

Често си мисля, че съм мъничко параноик. (И мъничко оптимист – понякога предвиждам вероятност за лоши неща, понякога за добри…) Но се боя, че моята оценка за мира в света в средносрочно бъдеще също клони към песимистична. Вероятността да се стигне до война в Европа засега ми се струва малка – да кажем, 10%. Но като се има предвид какви ще са последствията, това не е за пренебрегване… Накратко казано – личната ми преценка е да си живея живота щастливо и без страх от война, и да планирам мирни старини, но за всеки случай да имам в някое ъгълче на мозъка си план за действия при подобно развитие.

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

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

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

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

Част от нея, примерно сигналите на сирените, вероятно са различни за България. (За срам не знам българските.) Но много от нещата биха били от отлична полза и за българи. Естествено, у нас само кръгъл идиот ще разчита на правителството или общината да се погрижат за него с шведска добросъвестност. Или да организират съпротива срещу агресор, вместо да ни продадат на него срещу жълти стотинки, мисля си… Но много от съветите в брошурата касаят какви индивидуални действия следва да предприеме човек, за да подобри шансовете си за оцеляване.

За незнаещите английски си позволявам да преведа набързо някои от най-важните изречения и абзаци. (Тук-там с мои коментари.)


Извънредните ситуации могат да попречат на обществото да функционира както сме свикнали. Промените в климата могат да направят наводненията и пожарите по-чести. Катастрофи в други части на света могат да доведат до недостиг на някои храни. Проблеми във важни ИТ системи могат да попречат на електроснабдяването. Много бързо ежедневният ви живот може да се сблъска с проблеми:

– Отоплението спира да работи
– Съхраняването на храни и готвенето може да стане трудно
– Храни и други стоки могат да изчезнат от магазините
– Водоснабдяването може да спре
– Може да няма гориво за колата ви
– Банковите карти и банкоматите може да спрат да работят
– Мобилните телефони и Интернет може да спрат да работят
– Общественият транспорт (а и други видове транспорт) може да спре
– Лекарствата и медицинските услуги може да станат трудно достъпни

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

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

В случай на обществени затруднения, помощ ще бъде предоставена (от държавата и общините – Григор) първо на най-нуждаещите се. Мнозинството се очаква да могат да се справят сами, поне отначало. Колкото по-добре сте подготвени, толкова повече ще можете да помогнете на тези, които по една или друга причина не са подготвени.

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

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

Така ми се иска да бяхме такова общество. А си зависи само от нас – дори не от всички заедно, а от всеки поотделно… дано схващате намека.

Внимавайте за лъжлива информация

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

Най-добрата защита срещу лъжлива информация и враждебна пропаганда е критичната оценка на източника:

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

Търсете и преценявайте сами информацията. Най-добрият начин да противодействате на пропагандата и лъжливата информация е да сте си написали домашното.

Не вярвайте на слухове – използвайте повече от един надежден източник, за да прецените дали дадена информация е вярна.

Не разпространявайте слухове – ако дадена информация не е достоверна, не я предавайте по-нататък.

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

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

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

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

Домашна готовност


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

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


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

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

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


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

– вълнени дрехи
– топли дрехи за излизане навън в студено време
– шапки, ръкавици, шалове
– одеала
– дюшеци
– спални чували
– свещи
– кибрит или запалки
– горивно отопление – газови бутилки с котлон или горелка, парафинови отоплители…


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

– радио на батерии, слънчеви батерии или ръчно динамо
– автомобилно радио
– списък важни телефонни номера (на хартия)
– допълнителни батерии или пауърбанк за мобилни телефони и подобни
– зареждащо устройство за мобилни телефони, което може да се зарежда в кола


– спиртен (сух спирт) котлон и гориво за него
– фенерче, евентуално за глава
– батерии
– пари в дребни банкноти
– запас от често употребявани лекарства
– мокри кърпички
– дезинфектант за ръце
– тоалетна хартия и средства за менструална хигиена
– хартиени копия на важни документи, вкл. застраховки, банкова информация, регистрации
– гориво за колата

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

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

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

Ако Швеция е атакувана от друга държава, ние никога няма да се предадем. Всяка информация, че съпротивата трябва да се прекрати, е лъжа.

В реални условия дори Швеция може да се наложи да се предаде – но им се възхищавам на духа. Лично аз бих се замислил сериозно, преди да ги нападна.

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

Дано не се стига до това – но ако ситуацията стане напечена, идеята човек да е предварително информиран е чудесна. Не че в България имаме укрития за други освен слугите на народа, но все пак.

Научете се да оказвате първа помощ. Вашите познания могат да спасят животи. Ако сте първите, които пристигат на мястото на сериозен инцидент, веднага се обадете на телефон 112. Можете да звъните на него дори ако сметката ви не е платена или даже нямате SIM карта в телефона.

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

Медийна свобода и плурализъм

Post Syndicated from nellyo original https://nellyo.wordpress.com/2018/05/17/sofia_16052018/

В София се проведе международна  конференция “Медийна свобода и плурализъм: Как да рестартираме основния стълб на ЕС“.

Записи от   конференцията могат да се видят тук:  сесия  I and   сесия II) или тук.

Пълният текст на заключителната декларация, в края са  препоръките:

Свобода на медиите в Европа: Код червено

През 1997 г. Софийската декларация на ЮНЕСКО за свободни и плуралистични медии бе ревностен призив за напредък в контекста, в който появата на нови информационни и комуникационни технологии се считаше за нова възможност за плурализъм, икономическо и социално развитие, демокрация и мир. Сега, 21 години по-късно, независимите медии в Европа претърпяха безпрецедентен натиск. Комбинацията от различни фактори, като убийствата на журналисти и физическите заплахи срещу тях, нарастващия политически и институционален натиск, репресивното законодателство, насочено към медиите, разрушителните технологии и финансовата криза, поставят съществуването на свободните медии в редица европейски страни в риск.

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

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

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

Бюджет на ЕС и върховенство на закона

На 2 май 2018 г. Европейската комисия предложи бюджет за периода 2021-2027 г. и изготви стратегически план за наказване на страни, за които твърди, че са нарушили основните ценности на ЕС. Планът обвързва финансирането от Европейския съюз с принципите на правовата държава, но е твърде ограничен и не споменава свободата на медиите.

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

Предложението се очакваше и беше направено в отговор на Полша, първата и единствена страна, която досега е обект на механизма на върховенството на закона, тъй като ЕК установи системно поведение, поставящо демокрацията в опасност. Унгария също е на радара на Комисията, където демократичните условия се влошиха, след като продължителни усилия за институционализиране на “нелибералната демокрация” в страната. Полша и България, председателстваща Съвета на ЕС, бяха сред първите държави, които реагираха отрицателно на предложения нов регламент.

Убийства и физически заплахи

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

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

Икономическа устойчивост

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

За съжаление, през последното десетилетие значителна част от икономическата база на независимите медии е ерозирала. Медийните компании изпитаха двоен шок от кризата в бизнес цикъла и бизнес модела си.

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

Данните на Бюрото за интерактивна реклама от 2016 г. показват, че 89% от разходите за онлайн реклама са отишли за Google и Facebook, като останалите 11% са за всички останали дигитални играчи.
Много предложения на ЕС, свързани с дигиталната сфера, заплашват с тежки и несправедливи съдебни и административни процедури. Като например предложения за електронна конфиденциалност, които биха дали преимущество на най-силните технологични играчи и биха въпрепятствали по-малките играчи, които са зависими от «бисквитки» и от сложно сътрудничество с трети страни, за да бъдат част от икономиката на данни.

В много страни от ЕС икономическите трудности, които медийните компании са преживели, доведоха директно до концентрация на политически контрол над медиите и засилена зависимост от правителственото финансиране. В някои случаи управляващите политически елити използват средства на правителството и ЕС, за да подкрепят лоялните медии и да манипулират общественото мнение. В тези страни обществената телевизия и радио също са загубили независимост или са под нарастващ политически натиск. На практика тези процеси доведоха до това, че големи части от медийния пазар минаха под контрола на управляващите политици и техните поддръжници за целите на пропагандата, като същевременно предприеха тежки атаки срещу малкото останали независими медии. Близо сме до карйната «цел» за безотчетна власт в някои от страните в ЕС.

Код червено за медийната свобода в държави в Европейския съюз


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

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


Бизнесмените, които са в тесни връзки с партия «Фидес» на премиера Виктор Орбан, не само успяха да придобият нови медии през 2017 г., но и да заместят чуждестранните медийни компании, инвестирали в унгарски медии. Най-големият им успех бе поемането на контрол над последните три регионални ежедневника. Независимо от това, унгарският медиен пейзаж все още е разнообразен и печатни и онлайн издания не се колебаят да публикуват разследвания за предполагаема корупция, включваща най-влиятелните личности от Фидес и държавни служители. В Унгария съжителстват два типа медии. Единият се състои от проправителствени и про-Фидес медии, обсебени от темата за миграцията, “защитата на Унгария и нейните граници” и очернящата кампания срещу унгарско-американския милиардер филантроп Джордж Сорос.

Другият тип медии са насочени към разкриване на корупционни скандали. Оцеляването на медиите, критикуващи правителството, се дължи до голяма степен на бившия съратник на Орбан Лайош Симичка, който през февруари 2015 г. се разграничи публично от премиера и продължава да финансира медийна империя, създадена първоначално за подкрепа на Фидес. Правителството и неговите бизнес съюзници вече са се наточили на две медии – най-големият търговски канал RTL Klub и водещият политически информационен сайт Index.hu. И двете критикуват правителството.


През изминалите години свободата на медиите в България се влошава с тревожни темпове. Според световния индекс за свободата на медиите на Репортери без граници, България се е смъкнала със 75 позиции през последните 12 години – от 36-та през 2006 г. до 111-то през 2018 г. Налице е нарастващ политически натиск и нарастващ брой физически заплахи срещу разследващи журналисти, издатели и независими медии. Основният инструмент за упражняване на натиск е концентрацията на собственост върху медиите, икономическите зависимости и други форми на политически контрол върху по-голямата част от медийното пространство и монопол върху каналите за разпространение на медийно съдържание. Моделът включва също така силно влияние върху правителството, прокуратурата и съдебната власт, както и контрол над повечето независими регулатори. Всичко това представлява огромен политически и бизнес конгломерат, ръководен от действащия политик, бивш магистрат, бизснесмен и медиен собственик Делян Славчев Пеевски.

От 2009 г., с кратки прекъсвания, България е управлявана от ГЕРБ и техния лидер и премиер с три мандата – Бойко Борисов, който се радва на комфорт от страна на контролираните от Пеевски медии. Премиерът Борисов не само постоянно отказва да признае, че съществува заплаха за свободата на медиите, но играе ключова роля за увеличаване на достъпа на г-н Пеевски до публични ресурси, като същевременно му предоставя допълнителни институционални инструменти за репресия, включително законодателни решения, използвани срещу независимите медии.


2017-та бе белязана от бомбения атентат срещу Дафне Каруана Галиция, разследваща журналистка, която бе разкрила “мръсните тайни” на местната политика и косвено предизвика предсрочни общи избори през юни 2017 г. Години наред тя е била под нарастващ натиск заради популярността на нейния блог и работата ѝ по разплитане на местните връзки от т.нар. Досиета Панама и т.н. Към момента на убийството ѝ срещу нея вече са били заведени 42 граждански иска и пет наказателни дела за клевета. Тя също бе постоянен обект на заплахи и други форми на тормоз. Съдебният тормоз имаше за цел да я отстрани от обществения живот. Нейният случай беше класически пример за съдебни дела, в които влиятелни ищци се опитват да използват страха от огромни разходи за правна защита, за да затворят устата на критиците си. Под заплаха от страна на известни личности или бизнес групи, независимите медии са принуждавани да отстъпят и да премахнат публикации от своите сайтове.


Убийството на разследващия репортер Ян Куцяк през февруари 2018 г. предизвика безпрецедентен политически трус в Словакия и стресна международната общност. Куцяк провеждаше разследване за уебсайта Aktuality.sk относно предполагаеми връзки между италианската мафия и Smer-SD (ляво-популистката партия, която оглавява управляващата коалиция) и предполагаемото присвояване на средства от ЕС. В недовършена статия, публикувана след смъртта му, той обвинява премиера Роберт Фицо в пряко участие.

Министрите на културата и вътрешните работи бяха принудени да подадат оставка и след големи улични протести, самият Фицо трябваше да последва примера им. Подобно на други словашки политици, Фицо бе подложен на засилени атаки в медиите. През ноември 2016 г. той описва журналистите като “мръсни антисловашки проститутки” и ги обвинява, че се опитват да възпрепятстват европейското председателство на Словакия. Така той реагира в отговор на въпрос за предполагаеми нередности в обществените поръчки, свързани с председателството. При липсата на силни институции, които биха могли да ги защитят, журналистите в Словакия все повече са изложени на всякакъв вид тормоз, сплашване и оскърбления.

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

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


Трудно е да си представим президент да извади огнестрелно оръжие пред журналисти, но това направи президентът на Чешката република Милош Земан на пресконференция през октомври 2017 г., размахвайки «Калашников» с надпис “за журналисти”. Преизбран през януари 2018 г., Земан има слабост към този вид провокации и многократно е описвал журналистите като “оборска тор” и “хиени”. Президентът и няколко други политически лидери наскоро засилиха вербалните си атаки срещу независимостта на обществените медии, особено на Чешката телевизия. Също така има няколко нови законопроекти, които биха увеличили обхвата на наказателните санкции за клевета, особено клеветата срещу президента. Нивото на концентрация на собственост върху медиите стана критично, тъй като новите олигарси започнаха да използват своето богатство през 2008 г., за да купуват вестници и да засилят влиянието си. Един от тези олигарси, премиерът Андрей Бабиш, притежава един от най-влиятелните ежедневници в Чехия.

Препоръки за провеждане на бъдещи политики:

1. Журналистите, издателите, НПО и други ключови заинтересовани страни трябва да обединят усилията си за подобряване на ефективността при използването на механизми за правна защита в Съда на Европейския съюз и Европейския съд по правата на човека. Една практическа идея би могла да бъде създаването на експертно юридическо лице “Фонд за защита на свободата на медиите”, който да подпомага гражданите, независимите журналисти, издателите и медийните компании при прилагането на международните закони срещу злоупотребата с власт на местните правителства. Такъв фонд би могъл също да инициира и подкрепи независими международни разследвания на случаи на медиен натиск от високопоставени личности в държавите-членки на ЕС;

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

На 3 май 2018 г. Европейският парламент гласува резолюция, споед която Комисията трябва да работи за създаването на механизъм на ЕС за демокрация, върховенство на закона и основните права, придружен от независими механизми за наблюдение, които да оценят състоянието на свободата и плурализма на медиите и всички нарушения, свързани с това.

3. Медийният бизнес модел е в преход. Икономическото оцеляване на медийните компании и независимата журналистика на по-малките пазари е много трудно. Свободните медии обаче са крайъгълният камък на гражданското общество и функционирането на демокрацията. ЕС разглежда свободната преса и свободата на изразяване като “обществено благо” и трябва да разработи обществени механизми за устойчивото си финансиране, за да гарантира своята независимост. Това би могло да включва финансиране от ЕС, насочено пряко към журналисти и медийни компании в държавите-членки, като се избягва посредничеството на местното правителство;

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

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

Съд на ЕС: предоставяне на потребителски данни на полицията – кога?

Post Syndicated from nellyo original https://nellyo.wordpress.com/2018/05/16/ecj_privacy/

Известно е Заключението на Генералния адвокат по дело  C‑207/16 въз основа на преюдициално запитване, отправено от Audiencia Provincial de Tarragona (съд на провинция Тарагона, Испания).

Запитването се отнася до тълкуването на понятието „тежки престъпления“ по смисъла на практиката на Съда, установена с решение Digital Rights Ireland и решение Tele2 Sverige и Watson  – в които това понятие се използва като критерий за преценка на законосъобразността и пропорционалността на намесата в правата по членове 7 и 8 от Хартата на основните права на Европейския съюз  –  именно съответно правото на зачитане на личния и семейния живот, както и правото на защита на личните данни.

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


„1)      Може ли достатъчната тежест на престъплението като критерий, обосноваващ засягането на признатите в членове 7 и 8 от [Хартата] основни права, да се определи единствено с оглед на наказанието, което може да се наложи за разследваното престъпление, или е необходимо освен това да се установи, че с престъпното деяние се увреждат в особена степен индивидуални и/или колективни правни интереси?

2)      Евентуално, ако определянето на тежестта на престъплението с оглед единствено на наказанието, което може да се наложи, отговаря на конституционните принципи на Съюза, приложени от Съда на ЕС в решението му [Digital Rights] като критерии за строг контрол на Директивата[, обявена за невалидна с това решение], то какъв следва да е минималният праг за наказанието? Допустимо ли е по общ начин да се предвиди праг от три години лишаване от свобода?“.

Тоиз разговор е добре известен на българите от времето на прилагането на Директива 24/2006/ЕС за задържане на трафичните данни, обявена от Съда за невалидна. Тогава имаше разногласия по въпроса кое е тежко и кое е сериозно престъпление и как целта за защита на обществения интерес се съотнася с правото на защита на личния живот и личната кореспонденция. Генералният адвокат също прави препратка към Директива 24/2006/ЕС.

ГА по първия въпрос:

90.      Според мен следва да се внимава, за да не се възприеме твърде широко разбиране относно изискванията, поставени от Съда с тези две решения, за да не се препятства, или поне не прекомерно, възможността на държавите членки да дерогират установения от Директива 2002/58 режим, която им е предоставена с член 15, параграф 1 от същата, в случаите, в които разглежданите намеси в личния живот едновременно преследват законна цел и са с ограничен обхват, каквито е възможно да настъпят в случая в резултат от искането на разследващата полицейска служба. По-конкретно считам, че правото на Съюза допуска възможността за компетентните органи да имат достъп до държаните от доставчици на електронни съобщителни услуги данни за идентификация, позволяващи да се издирят предполагаемите извършители на престъпление, което не е тежко.

91.      С оглед на това препоръчвам на Съда да отговори на преформулирания преюдициален въпрос, че член 15, параграф 1 от Директива 2002/58 във връзка с членове 7 и 8 и член 52, параграф 1 от Хартата трябва да се тълкува в смисъл, че мярка, която за целите на борбата с престъпленията дава на компетентните национални органи достъп до идентификационните данни на ползвателите на телефонни номера, активирани с определен мобилен телефон през ограничен период, при обстоятелства като разглежданите в главното производство води до намеса в гарантираните от споменатата директива и Хартата основни права, която не е толкова сериозна, че да налага такъв достъп да се предоставя само в случаите, в които съответното престъпление е тежко.

ГА по втория въпрос:

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

107.  Ако понятието „тежко престъпление“ по смисъла на съдебната практика, установена с решения Digital Rights и Tele2, бъде прието от Съда за самостоятелно понятие на правото на Съюза, то би трябвало да се тълкува в смисъл, че тежестта на дадено престъпление, която може да оправдае достъпа на компетентните национални органи до лични данни съгласно член 15, параграф 1 от Директива 2002/58, трябва да се измерва, като се вземат предвид не само наказанията, които е възможно да бъдат наложени, но и съвкупност от други обективни критерии за преценка като упоменатите по-горе.

121. В заключение считам, че ако Съдът постанови — в разрез с това, което препоръчвам — че за да се квалифицира престъплението като „тежко“ по смисъла на неговата практика, установена с решение Digital Rights, следва да се отчита единствено предвиденото наказание, на втория преюдициален въпрос би следвало да се отговори, че държавите членки са свободни да определят минималния размер на съответното наказание за целта, стига да спазват изискванията, произтичащи от правото на Съюза, и по-специално онези изисквания, съгласно които намесата в основните права, гарантирани с членове 7 и 8 от Хартата, трябва да остане изключение и да бъде съобразена с принципа на пропорционалност.

Да напиша и името на този Генерален адвокат – Henrik Saugmandsgaard Øe от Дания. Успял да застане едновременно на най-разнообразни позиции, като един електрон.

Съвместима ли е таксата за радио и телевизия с правото на ЕС

Post Syndicated from nellyo original https://nellyo.wordpress.com/2018/05/13/fee_psm/

През март  2018 г. Oberverwaltungsgericht Rheinland-Pfalz (Върховен административен съд на Рейнланд-Пфалц – OVG Rheinland-Pfalz) решава, че таксата за радио и телевизия в Германия е съвместима с правото на ЕС (дело № 7 A 11938/17) . Съдът отхвърля тезата, че таксата е несъвместима с правото на ЕС, тъй като предоставя на обществените радио- и телевизионни доставчици на медийни услуги несправедливо предимство пред техните частни конкуренти.

Съдът посочва, че през 2016 г. Bundesverwaltungsgericht (Федерален административен съд – BVerwG) вече е установил съответствието на таксата  – в новата й форма, въведена през 2013 г. – с правото на ЕС (решение от 18 март 2016 г., BVerwG 6 С 6.15). Съгласно това решение въвеждането на таксата  не изисква съгласието на Европейската комисия и е с съвместимо с Директивата за аудиовизуалните медийни услуги.  Обществените и частните радио- и телевизионни оператори  неизбежно ще бъдат финансирани по различни начини. Това обаче не означава непременно, че обществените радио- и телевизионни оператори са получили несправедливо предимство, тъй като за разлика от частните радио- и телевизионни оператори те са подложени на много по-ограничителни правила за рекламиране и следователно са финансово зависими от таксата.

Междувременно Landgericht Tübingen (Районен съд в Тюбинген, решение от 3 август 2017 г., дело № 5 T 246/17 и др.) е постановил, че таксата  нарушава правото на ЕС  – и в резултат има подадено преюдициално запитване до Съда на ЕС –  дело  С-492/17.


Преюдициални въпроси:


Несъвместим ли е с правото на Съюза националният Gesetz vom 18.10.2011 zur Geltung des Rundfunkbeitragsstaatsvertrags (RdFunkBeitrStVtrBW) vom 17 Dezember 2010 (Закон от 18 октомври 2011 г. за прилагане на Държавния договор за вноската за радио- и телевизионно разпространение от 17 декември 2010 г., наричан по-нататък „RdFunkBeitrStVtrBW“) на провинция Баден-Вюртемберг, последно изменен с член 4 от Neunzehnter Rundfunkänderungsstaatsvertrag (Деветнадесети държавен договор за изменение на Държавните договори за радио- и телевизионно разпространение) от 3 декември 2015 г. (Закон от 23 февруари 2016 г., GBl. стр. 126, 129), поради това че вноската, събирана от 1 януари 2013 г. съгласно този закон безусловно по принцип от всяко живеещо в германската федерална провинция Баден-Вюртемберг пълнолетно лице в полза на радио- и телевизионните оператори SWR и ZDF, представлява помощ, която противоречи на правото на Съюза и предоставя по-благоприятно третиране само в полза на тези обществени радио- и телевизионни оператори спрямо частни радио- и телевизионни оператори? Трябва ли членове 107 и 108 ДФЕС да се тълкуват в смисъл, че за Закона за вноската за радио- и телевизионно разпространение е трябвало да се получи разрешението на Комисията и поради липсата на разрешение той е невалиден?


Трябва ли член 107 ДФЕС, съответно член 108 ДФЕС да се тълкува в смисъл, че в обхвата му попада правна уредба, установена в националния закон „RdFunkBeitrStVtrBW“, която предвижда, че по принцип от всяко живеещо в Баден-Вюртемберг пълнолетно лице безусловно се събира вноска в полза само на държавни/обществени радио- и телевизионни оператори, поради това че тази вноска съдържа противоречаща на правото на Съюза и предоставяща по-благоприятно третиране помощ с цел изключването по технически причини на оператори от държави от Европейския съюз, доколкото вноските са предназначени да се използват за създаването на конкурентен начин на пренос (монопол върху DVB-T2), без да е предвидено той да се използва от чуждестранни оператори? Трябва ли член 107 ДФЕС, съответно член 108 ДФЕС да се тълкува в смисъл, че в обхвата му попадат не само преки субсидии, но и други релевантни от икономическа гледна точка привилегии (право на издаване на изпълнителен лист, правомощия за предприемане на действия както в качеството на стопанско предприятие, така и в качеството на орган, поставяне в по-благоприятно положение при изчисляването на дълговете)?


Съвместимо ли е с принципа на равно третиране и със забраната за предоставящи привилегии помощи положение, при което на основание национален закон на провинция Баден-Вюртемберг германски телевизионен оператор, който се урежда от нормите на публичното право и има предоставени правомощия на орган, но същевременно се конкурира с частни радио- и телевизионни оператори на рекламния пазар, е привилегирован в сравнение с тези оператори поради това че не трябва като частните конкуренти да иска по общия съдебен ред да му бъде издаден изпълнителен лист за вземанията му срещу зрителите, преди да може да пристъпи към принудително изпълнение, а самият той има право, без участието на съд, да издаде титул, който същевременно му дава право на принудително изпълнение?


Съвместимо ли е с член 10 от ЕКПЧ /член [11] от Хартата на основните права (свобода на информация) положение, при което държава членка предвижда в национален закон на провинция Баден-Вюртемберг, че телевизионен оператор, на който са предоставени правомощия на орган, има право да изисква плащането на вноска от всяко живеещо в зоната на радио- и телевизионното излъчване пълнолетно лице за целите на финансирането на точно този оператор, при неплащането на която е предвидена глоба, независимо дали това лице въобще разполага с приемник или само използва услугите на други, а именно чуждестранни или други, частни оператори?


Съвместим ли е националният закон „RdFunkBeitrStVtrBW“, и по-специално членове 2 и 3, с установените в правото на Съюза принципи на равно третиране и на недопускане на дискриминация в положение, при което вноската, която следва да се плаща безусловно от всеки жител за целите на финансирането на обществен телевизионен оператор, налага на всяко лице, което само отглежда детето си, тежест в размер, многократно по-висок от сумата, дължима от лице, което живее в общо жилище с други хора? Следва ли Директива 2004/113/ЕО (1) да се тълкува в смисъл, че спорната вноска също попада в обхвата ѝ и че e достатъчно да е налице косвено поставяне в по-неблагоприятно положение, след като с оглед на реалните дадености 90 % от жените понасят по-голяма тежест?


Съвместим ли националният закон „RdFunkBeitrStVtrBW“, и по-специално членове 2 и 3, с установените в правото на Съюза принципи на равно третиране и на недопускане на дискриминация в положение, при което вноската, която следва да се плаща безусловно от всеки жител за целите на финансирането на обществен телевизионен оператор, за нуждаещите се от второ жилище лица по свързана с работата причина е двойно по-голяма, отколкото за други работници?


Съвместим ли е националният закон „RdFunkBeitrStVtrBW“, и по-специално членове 2 и 3, с установените в правото на Съюза принципи на равно третиране и на недопускане на дискриминация и със свободата на установяване, ако вноската, която следва да се плаща безусловно от всеки жител за целите на финансирането на обществен телевизионен оператор, е уредена по такъв начин, че при еднаква възможност за приемане на радио- и телевизионно разпространение непосредствено преди границата със съседна държава от ЕС германски гражданин дължи вноската само поради мястото си на пребиваване, докато германският гражданин, живущ непосредствено от другата страна на границата, не дължи вноската, също както гражданинът на друга държава — членка на ЕС, който по свързани с работата причини трябва да се установи непосредствено от другата страна на вътрешна граница на ЕС, понася тежестта на вноската, но не и гражданинът на ЕС, живущ непосредствено преди границата, дори и никой от двамата да не се интересува от приемането на излъчванията на германския оператор?

Коментар по въпрос №4:  допуснат е въпрос за съвместимост с чл.10 от Конвенцията за правата на човека. Съдът за правата на човека вече се е произнасял, има съображения за недопустимост по сходно дело отпреди десетина години –  ето тук съм писала – вж Faccio v Italy – но нека да се произнесе и Съдът на ЕС.

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

Чакаме решението на Съда на ЕС. Нека да се развива и множи практиката.

Електронни съобщения и услуги в ЕС: насоки за пазарен анализ на значителната пазарна сила

Post Syndicated from nellyo original https://nellyo.wordpress.com/2018/05/09/compet_eu/

В Официален вестник на Европейския съюз – Съобщение на Комисията с важно значение за конкуренцията на единния цифров пазар:

Насоки за пазарен анализ и оценка на значителната пазарна сила съгласно регулаторната рамка на ЕС за мрежите за електронни съобщения и услугите

Комисията прие насоки  за пазарен анализ и оценка на значителната пазарна сила   в съответствие с член 15, параграф 2 от Директива 2002/21/ЕО  след провеждане на обществена консултация, резултатите от която бяха надлежно отчетени. Насоките за ЗПС се придружават от обяснителна бележка и трябва да бъдат четени в контекста на допълнителната информация, посочена в нея.

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

Съгласно член 14, параграф 2 от Директива 2002/21/ЕО се приема, че предприятие притежава значително влияние на пазара, ако, било самостоятелно или съвместно с други, то има положение, равностойно на господстващо, т.е. положение на икономическа сила, даващо му възможността да действа в осезаема степен независимо от конкурентите, клиентите и в крайна сметка — потребителите.

Следните неизчерпателни критерии са от значение за измерването на пазарната сила на дадено предприятие да действа в значителна степен независимо от конкурентите, клиентите и потребителите:

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

Ако бъдат взети поотделно, горепосочените критерии няма непременно да бъдат от решаващо значение за констатирането на ЗПС. Такова констатиране трябва да бъде основано на съчетание от фактори.

Резолюция на ЕС относно плурализма и свободата на медиите в ЕС 2018

Post Syndicated from nellyo original https://nellyo.wordpress.com/2018/05/03/freedom-3/

След Peзолюция на Европейския парламент относно свободата на печата и на медиите по света  (2013 г.)  днес ЕП   гласува   Резолюция на ЕП относно  плурализма и свободата на медиите в Европейския съюз (488 гласа “за”, 43 “против” и 114 въздържали се).

Като има предвид, че […]

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

като има предвид, че Европейската аудио-визуална обсерватория на Съвета на Европа осъди възникването на цифров дуопол на Google и Facebook, представляващ до 85% от целия растеж на пазара на цифрови реклами през 2016 г., което застрашава бъдещето на традиционните финансирани от реклами медийни дружества, например търговските телевизионни канали, вестници и списания, чиято аудитория е много по-ограничена;

като има предвид, че в контекста на политиката на разширяване Комисията е длъжна да изисква пълно спазване на критериите от Копенхаген, включително свободата на изразяване на мнение и свободата на медиите, поради което ЕС следва да дава пример за най-високи стандарти в тази област; като има предвид, че когато станат член на ЕС, държавите са длъжни да спазват постоянно и безусловно задълженията в областта на правата на човека по силата на Договорите на ЕС и Хартата на основните права на ЕС, и като има предвид, че зачитането на свободата на изразяване на мнение и свободата на медиите в държавите членки следва да бъде обект на редовен контрол;

като има предвид, че ЕС може да се ползва с доверие на световната сцена единствено ако свободата на печата и медиите се защитава и зачита в рамките на самия Съюз […]

отправя над 60 препоръки към държавите и ЕК, всяка от които е самостоятелно важна.

В  резолюцията са записани препоръки  като:

47.  предлага с оглед на ефективната защита на свободата и плурализма на медиите да се забрани, или най-малкото да стане напълно прозрачно, участието в обществени поръчки на дружества, чийто краен собственик притежава също така и медийно дружество;

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

подчертава, че лица, които са били осъждани или признати за виновни в извършване на каквото и да било престъпление, не следва да бъдат собственици на медии;

48.  подчертава, че всяко публично финансиране на медийни организации следва да бъде предоставяно въз основа на недискриминационни, обективни и прозрачни критерии, за които всички медии да са предварително уведомени;

49.  припомня, че държавите членки следва да намерят начини за подпомагане на медиите, например като осигуряват неутралността на ДДС, както се препоръчва в неговата резолюция от 13 октомври 2011 г. относно бъдещето на ДДС и като подкрепят инициативите, свързани с медиите;

50.  призовава Комисията да разпределя постоянно и подходящо финансиране в рамките на бюджета на ЕС за подкрепа на мониторинга на плурализма на медиите на Центъра за плурализъм и свобода на медиите и за създаване на годишен механизъм за оценка на рисковете за плурализма на медиите в държавите членки; […]

51.  призовава Комисията да наблюдава и да събира информация и статистически данни относно свободата и плурализма на медиите във всички държави членки и да анализира отблизо случаите на нарушаване на основните права на журналистите, като същевременно спазва принципа на субсидиарност;

52.  подчертава необходимостта от засилване на споделянето на най-добри практики между регулаторните органи на държавите членки в аудио-визуалната сфера;

53.  призовава Комисията да вземе под внимание препоръките, съдържащи се в резолюцията на Европейския парламент от 25 октомври 2016 г. относно създаването на механизъм на ЕС за демокрацията, принципите на правовата държава и основните правапризовава Комисията да включи резултатите и препоръките от мониторинга на плурализма на медиите относно рисковете за плурализма и свободата на медиите в ЕС при изготвянето на годишния си доклад относно демокрацията, принципите на правовата държава и основните права (европейски доклад относно демокрацията, принципите на правовата държава и основните права);

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

55.  подчертава, че развиването на чувство за критична оценка и анализ по отношение на използването и създаването на медийно съдържание е от съществено значение, за да могат хората да вникват в актуалните проблеми и да оказват принос за обществения живот, както и за да бъдат те запознати с потенциала за промени и със заплахите, присъщи за все по-сложната и взаимосвързана медийна среда; подчертава, че медийната грамотност е основно демократично умение, което овластява гражданите; призовава Комисията и държавите членки да разработят конкретни мерки с цел насърчаване и подкрепа на проектите в областта на медийната грамотност като пилотния проект „Медийна грамотност за всички“ и да разработят цялостна политика за медийна грамотност, насочена към гражданите от всички възрастови групи и всички видове медии като неразделна част от политиката на Европейския съюз в областта на образованието, която да бъде целесъобразно подпомогната чрез съответните възможности за финансиране от ЕС, например европейските структурни и инвестиционни фондове и програмата „Хоризонт 2020“ [..]



2018-05-03 python, multiprocessing, thread-ове и забивания

Post Syndicated from Vasil Kolev original https://vasil.ludost.net/blog/?p=3384

Всеки ден се убеждавам, че нищо не работи.

Открих забавен проблем с python и multiprocessing, който в момента още не мога да реша чий проблем е (в крайна сметка ще се окаже мой). Отне ми прилично количество време да го хвана и си струва да го разкажа.

Малко предистория: ползваме influxdb, в което тъпчем бая секундни данни, които после предъвкваме до минутни. InfluxDB има continuous queries, които вършат тази работа – на някакъв интервал от време хващат новите данни и ги сгъват. Тези заявки имаха няколко проблема:
– не се оправят с попълване на стари данни;
– изпълняват се рядко и минутните данни изостават;
– изпълняват се в общи линии в един thread, което кара минутните данни да изостават още повече (в нашия случай преди да ги сменим с около 12 часа).

Хванаха ме дяволите и си написах просто демонче на python, което да събира информация за различните бази какви данни могат да се сгънат, и паралелно да попълва данните. Работи в общи линии по следния начин:
– взима списък с базите данни
– пуска през multiprocessing-а да се събере за всяка база какви заявки трябва да се пуснат, на база на какви measurement-и има и докога са минутните и секундните данни в тях;
– пуска през multiprocessing-а събраните от предния pass заявки
– и така до края на света (или докато зависне).

След като навакса за няколко часа, успяваше да държи минутните данни в рамките на няколко минути от последните секундни данни, което си беше сериозно подобрение на ситуацията. Единственият проблем беше, че от време на време спираше да process-ва и увисваше.

Днес намерих време да го прегледам внимателно какво му се случва. Процесът изглежда като един parent и 5 fork()-нати child-а, като:
Parent-а спи във futex 0x22555a0;
Child 18455 във futex 0x7fdbfa366000;
Child 18546 read
Child 18457 във futex 0x7fdbfa366000
Child 18461 във futex 0x7fdbfa366000
Child 18462 във futex 0x7fdbfa366000
Child 18465 във futex 0x7fdbf908c2c0

Това не беше особено полезно, и се оказа, че стандартния python debugger (pdb) не може да се закача за съществуващи процеси, но за сметка на това gdb с подходящи debug символи може, и може да дава доста полезна информация. По този начин открих, че parent-а чака един child да приключи работата си:

#11 PyEval_EvalFrameEx (
[email protected]=Frame 0x235fb80, for file /usr/lib64/python2.7/multiprocessing/pool.py, line 543, in wait (self== 1525137960000000000 AND time < 1525138107000000000 GROUP BY time(1m), * fill(linear)\' in a read only context, please use a POST request instead', u'level': u'warning'}], u'statement_id': 0}]}, None], _callback=None, _chunksize=1, _number_left=1, _ready=False, _success=True, _cond=<_Condition(_Verbose__verbose=False, _Condition__lock=, acquire=, _Condition__waiters=[], release=) at remote 0x7fdbe0015310>, _job=45499, _cache={45499: < ...>}) a...(truncated), [email protected]=0) at /usr/src/debug/Python-2.7.5/Python/ceval.c:3040

Като в pool.py около ред 543 има следното:

class ApplyResult(object):


def wait(self, timeout=None):
if not self._ready:

Първоначално си мислех, че 18546 очаква да прочете нещо от грешното място, но излезе, че това е child-а, който е спечелил състезанието за изпълняване на следващата задача и чака да му я дадат (което изглежда се раздава през futex 0x7fdbfa366000). Един от child-овете обаче чака в друг lock:

(gdb) bt
#0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1 0x00007fdbf9b68dcb in _L_lock_812 () from /lib64/libpthread.so.0
#2 0x00007fdbf9b68c98 in __GI___pthread_mutex_lock ([email protected]=0x7fdbf908c2c0 ) at ../nptl/pthread_mutex_lock.c:79
#3 0x00007fdbf8e846ea in _nss_files_gethostbyname4_r ([email protected]=0x233fa44 "localhost", [email protected]=0x7fdbecfcb8e0, [email protected]=0x7fdbecfcb340 "hZ \372\333\177",
[email protected]=1064, [email protected]=0x7fdbecfcb8b0, [email protected]=0x7fdbecfcb910, [email protected]=0x0) at nss_files/files-hosts.c:381
#4 0x00007fdbf9170ed8 in gaih_inet (name=, [email protected]=0x233fa44 "localhost", service=, [email protected]=0x7fdbecfcbb90, [email protected]=0x7fdbecfcb9f0,
[email protected]=0x7fdbecfcb9e0) at ../sysdeps/posix/getaddrinfo.c:877
#5 0x00007fdbf91745cd in __GI_getaddrinfo ([email protected]=0x233fa44 "localhost", [email protected]=0x7fdbecfcbbc0 "8086", [email protected]=0x7fdbecfcbb90, [email protected]=0x7fdbecfcbb78)
at ../sysdeps/posix/getaddrinfo.c:2431
#6 0x00007fdbeed8760d in socket_getaddrinfo (self=
, args=) at /usr/src/debug/Python-2.7.5/Modules/socketmodule.c:4193
#7 0x00007fdbf9e5fbb0 in call_function (oparg=
, pp_stack=0x7fdbecfcbd10) at /usr/src/debug/Python-2.7.5/Python/ceval.c:4408
#8 PyEval_EvalFrameEx (
[email protected]=Frame 0x7fdbe8013350, for file /usr/lib/python2.7/site-packages/urllib3/util/connection.py, line 64, in create_connection (address=('localhost', 8086), timeout=3000, source_address=None, socket_options=[(6, 1, 1)], host='localhost', port=8086, err=None), [email protected]=0) at /usr/src/debug/Python-2.7.5/Python/ceval.c:3040

(gdb) frame 3
#3 0x00007fdbf8e846ea in _nss_files_gethostbyname4_r ([email protected]=0x233fa44 "localhost", [email protected]=0x7fdbecfcb8e0, [email protected]=0x7fdbecfcb340 "hZ \372\333\177",
[email protected]=1064, [email protected]=0x7fdbecfcb8b0, [email protected]=0x7fdbecfcb910, [email protected]=0x0) at nss_files/files-hosts.c:381
381 __libc_lock_lock (lock);
(gdb) list
376 enum nss_status
377 _nss_files_gethostbyname4_r (const char *name, struct gaih_addrtuple **pat,
378 char *buffer, size_t buflen, int *errnop,
379 int *herrnop, int32_t *ttlp)
380 {
381 __libc_lock_lock (lock);
383 /* Reset file pointer to beginning or open file. */
384 enum nss_status status = internal_setent (keep_stream);

Или в превод – опитваме се да вземем стандартния lock, който libc-то използва за да си пази reentrant функциите, и някой го държи. Кой ли?

(gdb) p lock
$3 = {__data = {__lock = 2, __count = 0, __owner = 16609, __nusers = 1, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}},
__size = "\002\000\000\000\000\000\000\000\[email protected]\000\000\001", '\000' , __align = 2}
(gdb) p &lock
$4 = (__libc_lock_t *) 0x7fdbf908c2c0

Тук се вижда как owner-а на lock-а всъщност е parent-а. Той обаче не смята, че го държи:

(gdb) p lock
$2 = 0
(gdb) p &lock
$3 = (__libc_lock_t *) 0x7fdbf9450df0
(gdb) x/20x 0x7fdbf9450df0
: 0x00000000 0x00000000 0x00000000 0x00000000
0x7fdbf9450e00 <__abort_msg>: 0x00000000 0x00000000 0x00000000 0x00000000
0x7fdbf9450e10 : 0x00000000 0x00000000 0x00000000 0x00000000
0x7fdbf9450e20 : 0x00000000 0x00000000 0x00000000 0x00000000
0x7fdbf9450e30 : 0x001762c9 0x00000000 0x00000000 0x00000000

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

Та, явно това, което се е случило е, че докато parent-а е правел fork(), тоя lock го е държал някой, и child-а реално не може да пипне каквото и да е, свързано с него (което значи никакви reentrant функции в glibc-то, каквито па всички ползват (и би трябвало да ползват)). Въпросът е, че по принцип това не би трябвало да е възможно, щото около fork() няма нищо, което да взима тоя lock, и би трябвало glibc да си освобождава lock-а като излиза от функциите си.

Първоначалното ми идиотско предположение беше, че в signal handler-а на SIGCHLD multiprocessing модула създава новите child-ове, и така докато нещо друго държи lock-а идва сигнал, прави се нов процес и той го “наследява” заключен. Това беше твърде глупаво, за да е истина, и се оказа, че не е…

Около въпросите с lock-а бях стигнал с търсене до две неща – issue 127 в gperftools и Debian bug 657835. Първото каза, че проблемът ми може да е от друг lock, който някой друг държи преди fork-а (което ме накара да се загледам по-внимателно какви lock-ове се държат), а второто, че като цяло ако fork-ваш thread-нато приложение, може после единствено да правиш execve(), защото всичко друго не е ясно колко ще работи.

И накрая се оказа, че ако се ползва multiprocessing модула, той пуска в главния процес няколко thread-а, които да се занимават със следенето и пускането на child-ове за обработка. Та ето какво реално се случва:

– някой child си изработва нужния брой операции и излиза
– parent-а получава SIGCHLD и си отбелязва, че трябва да види какво става
– главния thread на parent-а тръгва да събира списъка бази, и вика в някакъв момент _nss_files_gethostbyname4_r, който взима lock-а;
– по това време другия thread казва “а, нямам достатъчно child-ове, fork()”
– profit.

Текущото ми глупаво решение е да не правя нищо в главния thread, което може да взима тоя lock и да се надявам, че няма още някой такъв. Бъдещото ми решение е или да го пиша на python3 с някой друг модул по темата, или на go (което ще трябва да науча).