At the Linux Application
Summit (LAS) in April, Sebastian Wick said that, by many metrics, Flatpak is doing great. The Flatpak
application-packaging format is popular with upstream developers, and
with many users. More and more applications are being published in the Flathub application store, and the
format is even being adopted by Linux distributions like
Fedora. However, he worried that work on the Flatpak project itself
had stagnated, and that there were too few developers able to review
and merge code beyond basic maintenance.
Version
5.5.0 of the Podman container-management tool has been
released. Notable features include the addition of a podman machine cp command to copy files into a running Podman
VM, a podman artifact extract command to copy
contents of an OCI
artifact to disk, and a --mount=artifact option to mount
OCI artifacts into containers. See the release announcement for a full
list of improvements and bug fixes.
From
servers in a data center to desktop computers, many devices
communicating on a network will eventually have to filter network
traffic, whether it’s for security or performance reasons. As a result,
this is a domain where a lot of work is put into improving performance:
a tiny performance improvement can have considerable gains.
Bpfilter is a
project that allows for packet filtering to easily be done with BPF, which can
be faster than other mechanisms.
Вчера във Fb групата Татковците на София имаше въпрос за поръчване на лекарство с рецепта, което е изчерпано от доста време в България. За съжаление, това се случва доста често и е отчасти заради схеми на болници и отделни лекари, но също и липсата на адекватен, а понякога какъвто и да е контрол на здравните и съдебните власти. Фактор е, че сме малък пазар и далеч не приоритет за резерви от дори критично важни лекарства. Доста хора прибягват към поръчване на лекарства от аптеки в Гърция. Описах вече как може да си поръчате препоръчителни ваксини като тези срещу менингит и хепатит А, където съхранението по цялата верига на доставка е важно. В случая на този татко обаче препаратът беше свършил и там.
Затова се разрових и писах на няколко аптеки в Германия, където може да се поръчва през интернет. Една Disapo ми отговори, че приемат рецепти от ЕС, но има няколко важни условия наложени им нормативно:
Рецептата трябва да се предостави в оригинал
Доставката трябва да е на адрес в Германия
Плаща се предварително и по цена непокрита от здравна каса
Уточнихме преди малко процесът и реших да го споделя, защото може да е полезен на някого. Важно уточнение е, че не съм поръчвал така – това са инструкциите на една аптека. За разлика от дистанционното вадене на ЕЗОК, ваксините или чиповете за тол пунковете в Гърция, където исках първо да мина целия процес преди да го споделя, тук нямам какво да поръчвам, за го пробвам.
Вземете рецепта от лекар с ясно изписано името на лекарството, подпис и печат
Направете си акаунт на фирма за доставки от Германия. Аз използвам GGBG.
Поръчайте от сайта лекарството избирайки производител и количество и изберете „Privatrecept“, т.е. не електронна от немски лекар
При поръчката въведете адреса в Германия на фирмата за доставки. Този на GGBG е в Берлин.
Изпратете рецептата с писмо до посочения от тях адрес в инструкциите. Добавете в писмото номер на поръчката. Препоръчвам да използвате куриер, но и с български пощи ще стане – просто последните може да отнемат между една и три седмици да пристигне писмото
Когато бъде обработена рецептата, ще получите инструкции за плащане
След като платите ще изпратят лекарството на фирмата за доставки, а те ще го докарат в България
Целият процес оскъпява лекарството по няколко причини. Първо, лекарствата в Германия без каса са доста по-скъпи от България. Въпросния препарат, който беше причината да проверя това, има двойна цена в Германия,… но е наличен. Второ, изпращането на писмо с куриер, ако бързате, не е евтино. Не на последно място макар доставката над 30 евро да е безплатна от самата аптека, доставянето до България ще струва още 5 до 10 лв. в зависимост дали искате да се донесе до вкъщи.
Разбира се, всичко може много да се опрости, ако познавате някой в Германия, изпратите му рецептата и той купи лекарството директно от аптека. Доста хора обаче нямат такива познати или не могат да чакат същите да пътуват за България. Във всеки случай, ако имате въпроси или намерите търсеното от вас лекарство в друга аптека, препоръчвам ви да им пишете. Тази тук просто беше първата, която ми отговори и то на добър английски.
Ако някой поръча така лекарства с рецепта от тази или друга аптека в тази или друга държава, моля да сподели опит в коментарите. Интересно ми е колко време отнема и дали има спънки.
Разбира се, за да не прибягваме до такива еквилибристики както за лекарства, така и за ваксини, трябва да изискваме доста по-настоятелно от Министерството на здравеопазването да ги осигурят в достатъчни количества. При това следва да го правим не само с коментари из фейса, а с търсене на сметка на народните ни избраници и висшите чиновници, от които пряко зависи това. Макар навсякъде да се случват проблеми с доставките в това турболентно време, няма две мнения, че сме свидетели на абсурдно отношение и бездействие към злоупотреби и критични липси.
On May 13, 2025, Fortinet disclosedCVE-2025-32756, an unauthenticated stack-based buffer overflow affecting multiple Fortinet products; including FortiVoice, FortiRecorder, FortiNDR, FortiMail, and FortiCamera. The vulnerability is rated as CVSS 9.6 (Critical), and allows an unauthenticated remote attacker to achieve remote code execution (RCE) against a vulnerable target.
Fortinet has disclosed that this vulnerability has been exploited in the wild by a threat actor who is targeting vulnerable FortiVoice appliances. No threat actor attribution has been made at this time. FortiVoice is an enterprise unified communication (UC) platform, providing communications services such as calling, conferencing, and chat. The Fortinet Product Security Team made this discovery based on observed threat activity. This threat activity included additional network scanning, credential logging, and log file wiping. Several IOCs have been published in the vendor advisory to assist customers in threat hunting.
Mitigation guidance
Fortinet have provided patches for affected versions under support, and guidance for unsupported versions to migrate to a fixed version. Customers are advised to follow the vendor guidance, and remediate this vulnerability by upgrading to a fixed version on an urgent basis, as outlined below.
FortiVoice 7.2 should be upgraded to 7.2.1 or above
FortiVoice 7.0 should be upgraded to 7.0.7 or above
FortiVoice 6.4 should be upgraded to 6.4.11 or above
FortiRecorder 7.2 should be upgraded to 7.2.4 or above
FortiRecorder 7.0 should be upgraded to 7.0.6 or above
FortiRecorder 6.4 should be upgraded to 6.4.6 or above
FortiNDR 7.6 should be upgraded to 7.6.1 or above
FortiNDR 7.4 should be upgraded to 7.4.8 or above
FortiNDR 7.2 should be upgraded to 7.2.5 or above
FortiNDR 7.1 should be migrated to a fixed release
FortiNDR 7.0 should be upgraded to 7.0.7 or above
FortiNDR 1.5 should be migrated to a fixed release
FortiNDR 1.4 should be migrated to a fixed release
FortiNDR 1.3 should be migrated to a fixed release
FortiNDR 1.2 should be migrated to a fixed release
FortiNDR 1.1 should be migrated to a fixed release
FortiMail 7.6 should be upgraded to 7.6.3 or above
FortiMail 7.4 should be upgraded to 7.4.5 or above
FortiMail 7.2 should be upgraded to 7.2.8 or above
FortiMail 7.0 should be upgraded to 7.0.9 or above
FortiCamera 2.1 should be upgraded to 2.1.4 or above
FortiCamera 2.0 should be migrated to a fixed release
FortiCamera 1.1 should be migrated to a fixed release
For customers who may not be able to update to a fixed version, Fortinet has given guidance to disable the affected appliance’s HTTP(S) administration interface. For the latest mitigation guidance, please refer to the vendor advisory.
Rapid7 customers
InsightVM and Nexpose customers can assess their exposure to CVE-2025-32756 on FortiVoice with an unauthenticated check expected to be available in the May 14, 2025 content release.
“Everything fails, all the time” – Werner Vogels, Amazon.com CTO
In today’s digital landscape, designing applications with resilience in mind is crucial. Resiliency is the ability of applications to handle failures gracefully, adapt to changing conditions, and recover swiftly from disruptions. By integrating resilience into your application architecture, you can minimize downtime, mitigate the impact of failures, and ensure continuous availability and performance for end-users.
Amazon Q Developer, a generative AI-powered assistant for software development lifecycle (SDLC), helps design resilient architectures and enhance application availability. It recommends best practices, analyzes code, and identifies potential failure points, serving as an expert companion to strengthen application architecture and boost system availability through the following key resiliency practices.
Resilient design pattern recommendations: Access tailored design patterns like distributed systems, microservices, and serverless architectures. Amazon Q offers recommendations across redundancy, robust failovers, and circuit breakers to boost resilience in your environment.
Disaster Recovery planning: Amazon Q offers expert guidance on comprehensive disaster recovery (DR), including efficient backups, systematic restorations, strategic data replication, and seamless failovers to ensure rapid recovery from disruptions with minimal impact.
Customized Resiliency testing frameworks: Create custom templates to simulate diverse failure scenarios, such as network degradation and infrastructure outages. This streamlines thorough resilience verification across your systems.
Failure mode evaluation: Use Amazon Q to conduct comprehensive Failure Mode and Effects Analysis (FMEA) identifying infrastructure vulnerabilities and assessing their impact. Amazon Q then ranks these issues by severity, enabling you to prioritize and address the most critical risks to protect your production environment.
In the following sections, we will demonstrate how Amazon Q improves the resiliency of a foundational application architecture.
Prerequisites
To begin using Amazon Q, the following are required:
We have a three-tier web application shown below that is running on AWS in a single Availability Zone (AZ). The architecture consists of Application Layer hosted on Amazon Elastic Kubernetes Service (Amazon EKS) cluster with two Amazon Elastic Compute Cloud (Amazon EC2) nodes in a single-AZ and the Data Layer uses Amazon Relational Database Service (Amazon RDS) instance deployed in single-AZ configuration. The architecture is functional but has several limitations. It poses a single point of failure and offers limited application availability with no fault tolerance. High response times may occur because there is no caching layer in front of the database. Additionally, the lack of auto-scaling can lead to resource contention.
Basic Application Overview
Enhance Application Resiliency
Let’s explore how Amazon Q helps incorporate resiliency best practices that enhance system availability in our basic application architecture.
Resilient architecture recommendations
The initial architecture faced challenges with reliability, performance and scalability, largely due to its single-point of failure and lacked redundancy. To address this, we described the existing application design and its challenges to Amazon Q using a natural language prompt to seek resiliency recommendations.
Prompt for improving the architecture design:
I have manually setup an application that runs within an EKS cluster on two EC2 nodes in single AZ. My application is not highly available and scalable. It talks to an RDS database which is single AZ. However, there is high response times from database. Provide me only the recommendations to re-design this application architecture at each layer that will addresses all these issues.
Amazon Q analyzed the provided context and recommended improvements such as introducing Multi-AZ deployments for high availability, adding auto-scaling groups for elasticity, and incorporating caching layers to enhance performance. These targeted recommendations helped redesign the architecture to be more resilient and scalable, directly addressing the initial shortcomings.
Disaster Recovery (DR) recommendations to improve the architecture
To further enhance resiliency, we prompted Amazon Q for disaster recovery (DR) recommendations. We asked for guidance aligned with the AWS Well-Architected Framework. This built upon the previously improved architecture design.
Prompt for recommendations on Disaster Recovery (DR) and architecture based on RTO/RPO
Based on the above improvements on AWS architecture design, share recommendations for Disaster Recovery (DR) based on AWS Well Architected Framework
Optionally, we can use advanced prompts like the below with additional context:
Please provide a recommendations to redesign my application that is running on an EKS cluster with two EC2 nodes and a single-AZ RDS database, addressing high database latency, low availability, and scalability issues. Suggest improvements across all architectural layers including presentation tier, application tier and data tier to enhance performance, resiliency, and scalability. Also, recommend DR strategies aligned with the AWS Well-Architected Framework focusing on resilience, data protection, and recovery.
Amazon Q tailoring recommendations based on business requirements using AWS Well-Architected Framework
Amazon Q provided detailed DR strategies. These included multi-region configuration, backup and restore procedures, and best practices for meeting specific Recovery Time Objective (RTO) and Recovery Point Objective (RPO) requirements.
Prepare DR strategy based on RTO and RPO requirements:
Diving further, asking for a specific disaster recovery strategy that meets the application RTO requirements of 2 hours and RPO requirements of 30 minutes.
Prompt for DR strategy based on RTO/RPO values
Which DR strategy should I use if my RTO is less than 2 hours and RPO is less than 30 minutes?
Amazon Q recommending disaster recovery strategy
Amazon Q recommended a Pilot light approach, detailing the setup and components needed to achieve the specified disaster recovery objectives.
Define resiliency testing workflow, identify key metrics and tools
As we incorporate resiliency best practices into the application architecture, its is important to employ a resiliency test workflow to ensure application’s resiliency requirements are met. To do this, we are asking for guidance to define an end-to-end resiliency testing process workflow. We also want to identify the key metrics and tools needed to test the resilience of each AWS service involved in the architecture.
Prompt for defining the resiliency testing workflow:
Define the end-to-end resiliency testing process workflow. Also, identify the key metrics and tools that should be used to test the resilience of each AWS service involved in the improved architecture design.
Amazon Q offering resiliency testing best practices and tools
Amazon Q offers a step-by-step approach to define resiliency testing experiments and prepare the environment for testing.
Failure mode evaluation to prioritize resiliency tests
Failure Mode and Effects Analysis (FMEA) can further assist with designing the resiliency tests. It is a proactive method to identify potential failures in processes or systems, assess their impact, and prioritize critical issues. It evaluates failure modes across hardware, software, human factors, and external events, enabling teams to develop strategies for prevention, detection, and mitigation, ultimately enhancing system resilience.
Leveraging Amazon Q, we requested a comprehensive FMEA report that includes components, cause, effect and their respective Risk Priority Numbers (RPN). RPNs are calculated by multiplying three key factors: Severity (S), Occurrence (O), and Detection (D). It helps organizations understand and prioritize which risks to address first.
Prompt for designing the FMEA template and scoring:
Create the FMEA in tabular format with scoring for improved architecture design above keeping in mind the RTO/RPO values and provide the steps for execution as well.
Amazon Q assisting with systematic risk assessment and FMEA report
Amazon Q intelligently incorporated previously defined RTO and RPO requirements to identify critical failure scenarios and calculated RPN for each potential incident.
Enhanced Architecture Implementing Resiliency Best Practices
After identifying the key pain points in our original architecture such as single points of failure, limited scalability, and lack of automated recovery, we leveraged Amazon Q to analyze our architecture to get targeted recommendations to elevate the resiliency. By describing our requirements and challenges to Amazon Q, we received actionable guidance on AWS best practices and service configurations, which we then implemented to transform our infrastructure for high resilience and availability.
Resilient Application Architecture
The original Application Layer was running in a single Availability Zone without auto-scaling, leading to potential downtime and performance bottlenecks. Amazon Q recommended distributing Amazon EKS worker nodes across multiple Availability Zones and enabling the Cluster Autoscaler to dynamically adjust node capacity based on traffic patterns. Additionally, it suggested implementing horizontal pod autoscaling within Amazon EKS to automatically scale application resources according to CPU utilization and custom metrics. Following these recommendations, we deployed Amazon EKS worker nodes across three Availability Zones, configured Cluster Autoscaler and horizontal pod autoscaling, and integrated an Application Load Balancer, to intelligently distribute incoming traffic. These changes significantly improved scalability, fault tolerance, and performance.
The Data Layer initially relied on a single-instance Amazon RDS deployment, which posed a risk of downtime and limited read performance. Upon review, Amazon Q advised implementing a Multi-AZ Amazon RDS configuration to enable automated failover and improve availability. It also recommended deploying read replicas to offload read-heavy workloads and enhance performance. Furthermore, Amazon Q suggested adding a Multi-AZ Amazon ElastiCache for Redis to reduce database load and speed up data access. We incorporated these recommendations, resulting in a more resilient and performant data layer capable of handling failover scenarios and scaling read operations efficiently.
The Presentation Layer lacked an optimized content delivery mechanism and comprehensive security controls. Amazon Q recommended integrating Amazon CloudFront as a content delivery network to accelerate the delivery of static content and reduce load on application servers. It also suggested deploying AWS WAF to protect against common web exploits. To improve operational visibility, Amazon Q emphasized the importance of comprehensive monitoring using Amazon CloudWatch, combining logs, metrics, and traces for rapid issue detection and resolution. Implementing these recommendations enhanced both the performance and security posture of the presentation layer.
Conclusion
Amazon Q Developer transforms how teams build resilient applications by serving as your expert companion throughout the development journey. Its guidance helps create systems that excel in resilience, scalability, and availability—critical factors for today’s demanding digital landscape. Amazon Q goes beyond theoretical advice by providing practical, step-by-step implementation guidance. In the above, we’ve witnessed how Amazon Q’s expertise can transform basic architectures into robust, failure-resistant systems. Its recommendations such as Multi-AZ redundancy, elastic scaling, strategic caching, and proactive resilience testing create applications that maintain performance and availability even during significant disruptions.
Ready to strengthen your applications against unexpected challenges? Harness Amazon Q’s capabilities to create resilient infrastructure that consistently delivers for your customers, regardless of conditions. Unlock the full potential of your AWS infrastructure and deliver uninterrupted service to your customers, today. To learn more about Amazon Q refer to the documentation.
Достъпността е важна не само за нашата архитектурна, физическа среда, но и за дигиталната. А нейното значение за ежедневието ни непрекъснато нараства – от предварителното задаване на маршрут, преглеждането на новините, онлайн плащанията, търсенето на информация до издаването на документи. Дигиталните услуги за всички тези дейности трябва да отговарят на Европейския акт за достъпност (ЕАД), който влиза в сила на 28 юни 2025 г.
Достъпност ли е, ако човек с различни възможности може да стигне до магазин, но не и да поръча онлайн?
EAД е ключова стъпка към общи стандарти за улеснено ползване на продукти и услуги, с които се подобрява качеството на живот не само на хората с различни възможности, но и на цялото общество.
Това не е първата директива за дигиталната достъпност в ЕС. Съществува и Директива (ЕС) 2016/2102, известна като Директивата на ЕС за уеб достъпността. Тя обаче се фокусира само върху уебсайтове и мобилни приложения на организации от обществения сектор, докато ЕАД важи и за частния сектор, с някои малки изключения.
ЕАД задължава бизнеса да прилага принципите на достъпност, заложени в акта, който е естествено продължение на адаптирането към Конвенцията на ООН за правата на хората с увреждания. По този начин се подчертава ангажираността на Европа с изграждането на една по-достъпна среда за всички.
Директивата се отнася до производството на потребителски технологични продукти, финансовите услуги, електронната търговия на дребно, транспорта, медиите и комуникациите, както и до спешните телефонни номера.
Единният европейски номер за спешни повиквания 112 впрочем е достъпен за хора с увреждания от януари 2019 г. Тогава е внедрена услуга, която осигурява лесен достъп за хора със слухови и/или говорни увреждания до този номер. Тя може да се ползва през интернет, чрез мобилно или уеббазирано приложение.
На ЕАД трябва да отговарят компютрите и мобилните устройства, смарттелевизорите, устройствата за стрийминг и възпроизвеждане на видео, игровите конзоли, електронните книги и четци. Също така и платформите за стрийминг и видео по заявка, обществените радиа и телевизии, мобилната телевизия.
Новите изисквания важат и за платформите за онлайн и мобилно банкиране, банкоматите и изобщо за всички места, където може да си купите нещо с карта, в т.ч. за онлайн магазините. От тях не са изключени и машините за продажба или чекиране на билети на гари, летища и във всякакви транспортни средства.
За кого важи Европейският акт за достъпност?
ЕАД изисква всички продукти и услуги в ЕС да бъдат достъпни за хора с увреждания, като определя пет категории, наричани икономически оператори, които трябва да отговарят на нейните изисквания. В тези категории влизат производителите, предлагащи продукцията си на пазара, независимо дали са физически лица, или предприятия, техните представители, вносителите, дистрибуторите и доставчиците на услуги.
Микропредприятията са частично освободени от съответствие с ЕАД. Те се определят като предприятия с по-малко от 10 служители, чийто оборот или общ годишен баланс не надвишава 2 млн. евро.
ЕАД налага минимални стандарти за достъпност и изисква гаранции, че уебсайтове, мобилни приложения и софтуерни интерфейси отговарят на Насоките за достъпност на уебсъдържание. Тези гаранции може да се осигурят чрез различни варианти на каналите за достъп (например текстови алтернативи на изображения, навигация чрез клавиатура, аудиоописания). Друга възможност е разработването на продукти, които може да се използват с помощни технологии, като екранни четци или адаптивни устройства.
Важно е да отбележим, че реално ЕАД дава само насоки на организациите, но достъпността е много повече от придържането към тях. Например фактът, че даден уебсайт отговаря на изискванията до степен, че текстът е достъпен за електронните четци и може да се променят контрастът и големината на шрифта, по никакъв начин не гарантира, че хората могат лесно да се ориентират, да разбират информацията и да намерят важната за тях.
Ако на „нормален“ човек му отнема, да кажем, минута да си поръча пица, а на един човек, който е незрящ и ползва екранен четец – пет минути, това е съществена разлика в достъпа.
Числа, които говорят
Спазването на изискванията за достъпност трябва да се разглежда не само като регулаторно задължение, а и като възможност за разширяване на пазара. По оценки на Европейската комисия над 135 млн. души в ЕС живеят с някаква форма на увреждане.
Последният доклад наWebAIM Millionза 2025 г. включва анализи на данни от 1 млн. най-посещавани начални страници в интернет. Една от основните констатации в доклада е, че на всяка от тези страници има средно 51 различни грешки по отношение на достъпността. Освен това броят на елементите на началните страници расте от година на година. Това увеличава сложността на навигацията и затруднява потребителите, особено тези с увреждания.
Сред основните констатирани проблеми са ниският контраст на текста (в 81% от изследваните страници) и липсващият алтернативен текст за изображения (55%). В 49% от страниците няма „етикети“ за формуляри, които да улеснят хората с нарушено зрение, които също така не могат да се ориентират и в разбирането на линковете на 45% и бутоните на 28% от сайтовете. 17% от началните страници не указват езика на документа, което е важен фактор за правилното функциониране на екранните четци.
Достъпността е основен фактор при изграждането на дигитални услуги. Това означава използване на ясен и разбираем език, интуитивен дизайн и адаптивност към различни устройства. Най-често хората, които най-много се нуждаят от дадена услуга, са тези, които срещат най-големи трудности при използването ѝ. Затова от самото начало трябва да мислим как да направим услугата максимално достъпна за всички, независимо от техните способности или технически познания.
Как един сайт може да стане по-достъпен
Трудно ще направим един сайт по-достъпен, ако не го тестваме с реални хора. Съществуват обаче определени практики, за които вече е натрупан достатъчно опит, че затрудняват определени групи лица, например:
създаване на достъпни версии само за определен браузър или операционна система;
поставяне на активни бутони много близо един до друг – това е предизвикателство за хората с проблеми с моториката;
слагане на таймер при извършването на определени задачи, например онлайн плащане – това създава напрежение у хората с когнитивни различия;
ясна ориентация докъде е стигнал потребителят в процеса (например при поръчка на самолетен билет) – не всички притежават перфектна концентрация;
избягване на CAPTCHA с картинки като тази по-долу, която е бариера за незрящите.
Контекстът, в който потребителите използват услугите, е от съществено значение. Дизайнът не трябва да се ограничава само до екрана, а да отчита реалните условия, в които хората взаимодействат с технологията. Например потребителите може да използват дадена услуга в движение, на мобилно устройство или в среда, където достъпът до интернет е ограничен. Нужно е да се мисли за всички тези фактори при изграждането на услугата. Затова и е важно да се провеждат съпътстващи потребителски проучвания.
Последователността в дизайна е важна, но тя не бива да се бърка с еднообразието. Когато използваме утвърдени дизайнерски модели, улесняваме потребителите, защото те вече са запознати с тях. Въпреки това моделите подлежат на адаптация. Гъвкавото и отворено отношение към промените е основен фактор за устойчивото развитие на дигиталните услуги и наистина правят живота на хората по-лесен.
Певицата и авторка на бестселър Хедър Хътчинсън, която е незряща по рождение, споделя, че цял живот са ѝ казвали да почака „5–10 години“, докато проблемите, свързани с увреждането ѝ, се решат:
Целият ми живот е „изчакай още 5–10 години. Най-голямата промяна, на която се надявам през следващите 5–10 години, е промяната в отношението на хората към уврежданията. Ние не чакаме да станем „цялостни“ и „пълноправни“ хора след 5–10 години, когато се появи лек или когато самоуправляващите се коли станат реалност. Хората с увреждания сме пълноценни хора – точно такива, каквито сме днес.
Примерът на Великобритания
Вместо да помагат, сложните системи и дълги информационни полета често затрудняват потребителите. Такива примери може да се видят на повечето сайтове на общини, държавни агенции и т.н. Истинското предизвикателство е да се създадат интуитивни и лесни за използване решения. А това не може да се постигне без отхвърляне на остарели и неефективни практики дори ако се ползват от години.
Искаме да споделим един добър пример от Обединеното кралство и историята на правителствения сайтGOV.UK. Отправната точка за създаването му е била не как правителството иска хората да ползват уебсайта, а как хората искат да го ползват. Така резултатът се оказва не просто уебсайт, а фундаментална промяна в начина, по който обществото взаимодейства с държавните институции.
GOV.UK представлява новаторски подход, който значително намалява разходите и подобрява достъпността и ефективността на обществените услуги. Платформата спестява на данъкоплатците приблизително 70 млн. паунда годишно. Но най-голямото постижение е поставянето на потребителите в центъра на услугата.
Разработката на уебсайта е основана на принципите на отвореност и постоянна обратна връзка. GOV.UK се изгражда и тества публично, като по този начин позволява реални потребителски мнения и идеи да бъдат интегрирани в подобренията. Платформата не просто отговаря на настоящите очаквания, но и се съобразява с бъдещите нужди на обществото и това съдейства държавната администрация да става по-компактна, по-бърза и по-адаптивна към нуждите на гражданите.
Достъпността не става случайно – тя се създава
Ако искаме дигиталните услуги, които създаваме, да са наистина достъпни, смислени и удобни за всички, това няма как да стане спонтанно. Нужен е съзнателен избор. Нужен е дизайн. И тук говорим не за дизайн на бутони или екрани, а за нещо много по-цялостно — дизайн на услуги.
Дизайнът на услуги е системен подход. Не се занимава само с това как изглежда даден продукт, а как реално функционира – за хората, които го ползват, и за онези, които го предоставят. Използва се т.нар. включващ дизайн – метод, при който се отчитат различията между хората и стремежът е да не се изключва никой.
Тук работата на дизайнера започва с въпроси. Но не „Как да направим това по-бързо?“, а „Трябва ли изобщо да го има?“, „Къде губим доверието на хората?“, „Какво кара потребителите да се отказват?“. Целта е да се види системата в пълнота – не само приложението или уебсайтът, а цялостното преживяване при използването ѝ.
Дизайнът на услуги не се интересува единствено от визията, а съчетава стратегии, технологии, поведение и комуникация в едно. Затова намира приложение в най-различни сектори – от публичната администрация до частния бизнес.
Нека дадем пример с платформите за доставка на храна. Да си представим, че проучване е установило, че някои потребители са объркани и се изнервят, когато не знаят къде е поръчката им. Ето какво могат да въведат компаниите:
карта с реално време на GPS проследяване на доставчика;
възможност за директен чат с доставчика;
автоматично известяване и компенсации при забавяне – без нужда от обаждане.
Този пример не се отнася пряко до хората с увреждания, но той илюстрира, че става дума не просто за „добавяне на функции“, а за системно мислене за преживяването като цяло.
ЕАД има за цел да подсигури, че всеки възможен клиент, независимо от увреждането си, може да ползва подобна платформа.
Важно е да се разбере: дизайнер на услуги не е строго дефинирана професия. В една организация това може да е UX дизайнер, специализиран в потребителското преживяване, в друга – стратегически консултант, в трета – човек, който оптимизира бекенд процеси, т.е. софтуера, който е зад видимата част на страниците.
Дизайнът на услуги не е инструмент за естетика. Той е инструмент за смисъл. Помага на организациите да проектират услуги, които не просто се „ползват“, а работят добре за хората – във всеки етап от взаимодействието.
И когато говорим за достъпност, тук тя вече не е просто функция или опция в менюто, а и начин на мислене, заложен в самата архитектура на услугата. Създаването ѝ започва с въпроса „Как можем да направим тази услуга така, че да работи за всички – не само за най-опитните, най-здравите и най-информираните, а и за онези, които най-често биват пренебрегнати или възпрепятствани?“.
Прилагането на Директивата служи за отправна точка. Но се надяваме да го видим приложено с вдъхновение и новаторство, за да създаваме смислени и безпрепятствени преживявания, а не просто уебстраници.
В настоящата ни съвместна поредица с „Екипът на София“ обсъждаме планирането, озеленяването, архитектурата, инфраструктурата, мобилността и още много други градски теми, описваме добрите примери и търсим възможните решения за подобряването на качеството на живот в нашите градове.
Let’s Encrypt will no longer include the “TLS Client Authentication” Extended Key Usage (EKU) in our certificates beginning in 2026. Most users who use Let’s Encrypt to secure websites won’t be affected and won’t need to take any action. However, if you use Let’s Encrypt certificates as client certificates to authenticate to a server, this change may impact you.
To minimize disruption, Let’s Encrypt will roll this change out in multiple stages, using ACME Profiles:
Today: Let’s Encrypt already excludes the Client Authentication EKU on our tlsserver ACME profile. You can verify compatibility by issuing certificates with this profile now.
October 1, 2025: Let’s Encrypt will launch a new tlsclient ACME profile which will retain the TLS Client Authentication EKU. Users who need additional time to migrate can opt-in to this profile.
February 11, 2026: the default classic ACME profile will no longer contain the Client Authentication EKU.
May 13, 2026: the tlsclient ACME profile will no longer be available and no further certificates with the Client Authentication EKU will be issued.
Once this is completed, Let’s Encrypt will switch to issuing with new intermediate Certificate Authorities which also do not contain the TLS Client Authentication EKU.
For some background information, all certificates include a list of intended uses, known as Extended Key Usages (EKU). Let’s Encrypt certificates have included two EKUs: TLS Server Authentication and TLS Client Authentication.
TLS Server Authentication is used to authenticate connections to TLS Servers, like websites.
TLS Client Authentication is used by clients to authenticate themselves to a server. This feature is not typically used on the web, and is not required on the certificates used on a website.
After this change is complete, only TLS Server Authentication will be available from Let’s Encrypt.
This change is prompted by changes to Google Chrome’s root program requirements, which impose a June 2026 deadline to split TLS Client and Server Authentication into separate PKIs. Many uses of client authentication are better served by a private certificate authority, and so Let’s Encrypt is discontinuing support for TLS Client Authentication ahead of this deadline.
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.