Coder Legion - Recent posts tagged cloud-security

EU's Controversial Chat Control Amendment Passed and Potential Security Implications

Mon, 13 Jul 2026 05:56:00 +0000

On July 3rd, 2026, a controversial amendment was passed to an already controversial legislation described by many as a normalization of mass surveillance and undermining legitimate users' privacy online. In this article, we will dive deeper into the security implications for messaging service platforms.

Scanning User Messages

As per the new amendment that was passed, platforms will be able to voluntarily scan user messages that are not encrypted end-to-end for any material involving child sexual abuse. This means messaging platforms like those on mainstream social media will be able to run scans over private messages between users, including photos, texts, and maybe even videos, to detect any potentially illegal material.

In practice, messaging platforms now have a legal basis to read private messages between users and hide behind the new amendment.

How?

The big question is more technical rather than legal. However, the implications can be severe for both users and platforms, especially if platforms don't have a properly structured solution.

The most obvious solution that comes to mind is that they could create a cadence for running all the stored messages to be scanned by an LLM solution and configure alerts for any content that could raise red flags to be reviewed by the platform and potentially reported and delivered to the corresponding authorities either through a legal team or a dedicated platform. I'm not aware at the moment of any platforms that are made for such a purpose, but I'm speculating how this could work in practice.

If private user messages are encrypted at rest, this means there will also be a considerable computing cost for platforms to decrypt the content during the scanning periods.

If we take Telegram as an example, Telegram claims that they deliver 15 billion messages per day as of July 13, 2026. We do not know how many of those messages belong to their secret chat feature, so let's assume that the majority of the messages are not encrypted end-to-end.

Technical Risks

If we assume that platforms will rely on LLM-based solutions, we have to discuss the risks.

AI False Positives and Bias

LLMs do make mistakes. This is why NIST AI RMF as well as OWASP Top 10 AI Security and Governance standards require human-in-the-loop for sensitive decisions. While human-in-the-loop is considered a best practice for sensitive decisions, bringing AI into the mix also brings with it all the common risks, including overconfidence, LLM bias, and drift.

Just running an AI scan doesn't mean that it will always properly classify the content. AI would be great for existing content but not for new content if AI isn't trained for it.

Scanning Tools

Effective scanning solutions are usually vendor-provided and bring with them their own risks, since any mistake on the vendor's side could expose all users' private data and even cause a data breach. Scanning tools that use LLM integrations require exposing the decrypted users' private messages to an external party. If not handled securely on both ends of the process (platform and vendor), the risk and potential of data breaches increases further.

Average Users Think Messages Are Private

Let's be honest. The majority of platform users aren't technical. I have personally encountered countless people who use private messages to store secrets such as credit card numbers, passwords, and other personal and sensitive content.

Platforms have no way to prevent users from using private messages in that capacity, and this is why platforms do not have the incentive to scan users' messages in the first place, as this would arguably impact their profits as well as expose them to legal liabilities.

Alternative Solutions

One way in which platforms could perform a scan without compromising users' privacy (at least before an alert is triggered) is to instead perform hash-based comparisons.

If platforms have specific files or texts to monitor for, they could compare the hashes instead of the decrypted content.

There Is No Perfect Solution

Even if we deploy hash-based detection instead of scanning users' private messages, the compute cost would be huge because not only do some platforms have to keep content encrypted at rest but also run hashing algorithm comparisons to detect the content in question if it exists.

Hashing also can be useful only for common or known content. So hashing wouldn't be that useful to spot modified content.

AI could do slightly better in terms of spotting patterns. However, this takes us again into the issues and risks mentioned earlier.

Environmental Impact

The sheer volume of messages exchanged daily globally between users is already stressing data centers that are trying to expand their capacity to accommodate both regular companies' needs as well as AI.

The carbon footprint of scanning users' private messages at scale will only increase the burden on an already heating planet.

Ethical Considerations

Relying on AI LLMs to flag users could have severe consequences on human rights if someone is flagged or accused of something illegal by mistake or by error. Even with human-in-the-loop, human biases could also lead to discrimination and bias based on the user's legally protected traits such as language, nationality, or religion.

The fact that human intervention might be needed (platform's forensic or security teams) to manually review flagged content and potentially users' private conversations raises serious implications for users' privacy. Just because an AI flagged a certain user's messages doesn't mean that they are automatically guilty.

In edge cases, users might accidentally share content that may seem, at surface, like a meme and end up in criminal prosecution. The accusation alone could have severe implications on a person's life in terms of society, their own family, and more.

Alternative Solutions

In my opinion, all children deserve protection. Violation of privacy of individuals or groups online is not protection in the pure sense. A more effective strategy to combat child abuse is by grassroots movements, awareness campaigns, and better legislation that addresses structural problems such as inequality and domestic violence.

Useful Sources

https://oeil.europarl.europa.eu/oeil/en/document-summary?id=1891790

https://telegram.org/blog/100-million

How Do You Protect Privacy & Security in Cloud Platforms Amid Encryption Risks and AI Threats?

Sat, 06 Jun 2026 05:33:38 +0000

Originally inspired by this Quora question:

“How do you protect the privacy & security in ‘the cloud platforms’
in an era of compromised encryption, government backdoors, & AI-driven
hacking threats to encryption & user confidentiality?”

Source: Quora question URL

Nowadays, companies are more gearing towards open-source solutions. While mainstream cloud providers such as AWS, Azure and others are still being used, security best practices still apply regardless of the cloud provider. In addition, companies increasingly adopting a mix between native cloud solutions and open-source for the same reason. This is why containers are important.

Some companies that adopt a multi-cloud strategy reduce confidentiality risks by having for example encryption keys handled by third party (not with the same cloud provider). This allows them to reduce the risks of vendor’s insider threats.(Check below figure)

This strategy helps isolate the data from the cloud providers and reduce vendor related risks.

As for encryption, AES 256 based encryptions are still considered strong enough. Quantum computing will definitely require many organizations to change their encryption algorithms but good news is that Quantum resistant encryption is already taking pace in the market.

AI vulnerabilities are real and this is why companies that are taking structured approach towards AI, are using AI to mitigate AI related risks.

Government backdoors are a real problem that hurts both businesses and public trust. This is why we will see more and more adoption of End-to-End encryption. Currently a lot of platforms have either true E2E or semi-E2E. End-to-End encryption became now almost a trust standard but some companies unfortunately are using deceptive tactics to promote themselves as E2E when they actually are not.

To prove that E2E solves the problem of backdoors, there were attempts by the UK government to ban it in 2015 but it didn’t go through. (Ellis, C. (2018). ‘On Backlash: Emotion and the Politicisation of Security.’ Politics, 38(3), pp. 267–284. Political Studies Association, UK.)

From commercial perspective, no business benefits from having compromised security or government backdoors because it hurts clients’ trust and confidence.

Organizations quite often think that compromising privacy improves security but as a matter of fact, it doesn’t. There are always other alternative methods that organizations can follow without compromising privacy but it boils down to leaders to be aware of the risks of solutions that compromise privacy.

Source: Quora question → [https://www.quora.com/How-do-you-protect-the-privacy-security-in-the-cloud-platforms-in-an-era-of-compromised-encryption-government-backdoors-AI-driven-hacking-threats-to-encryption-user-confidentiality]

Understanding Cloud Security with AWS Identity and Access Management (IAM)

Sun, 20 Apr 2025 10:15:43 +0000

In the AWS Shared Responsibility Model, AWS is responsible for the security of the cloud, while customers are responsible for security in the cloud. This means customers are accountable for securing the AWS services they use, such as Amazon EC2, Amazon S3, Amazon VPC, Amazon DynamoDB, Amazon RDS, Amazon IAM, and more.

In this article, we’ll focus on Cloud Security with AWS Identity and Access Management (IAM)—a powerful tool for controlling access to AWS resources.

What is AWS IAM?

AWS Identity and Access Management (IAM) is a web service that allows you to securely manage access to AWS resources. With IAM, you define who can access what and under what conditions. It provides the infrastructure necessary to manage authentication (who can sign in) and authorization (what they can do) across your AWS account.

Identities in IAM

When you first create an AWS account, you start with a root user—the identity that has full access to all AWS services and resources. This root user is tied to the email address used during account creation.

Security Best Practice: Avoid using the root user for day-to-day tasks. Instead, create an IAM user with administrative privileges and use that for regular operations.

Access Management

Once a user is created in IAM, they can authenticate using their credentials. IAM evaluates whether the user has permission to access specific AWS resources. This is determined by the policies attached to the user or their group or role.

For instance, when a user selects a service in the AWS Console, a request is sent to check:

Is the user authorized?
What policies are in place?
Are there any additional restrictions?

IAM ensures only authorized principals (users, roles, or federated identities) can access resources.

With IAM, you can:

Create users and user groups
Assign fine-grained permissions
Enforce security controls like MFA and password policies
Define who can do what across your AWS account

Key Components of IAM

IAM Users

These represent individuals who need access to your AWS resources—like you or your teammates.

IAM Groups

User groups (e.g., "Admins", "Developers") allow you to manage permissions collectively. Policies attached to a group apply to all its users.

IAM Roles

Roles provide temporary access to AWS resources. They're ideal for:

Applications running on EC2
Users from another AWS account
Federated users from corporate directories

IAM Policies

Policies are JSON or Visual Editor documents that define permissions. A policy specifies:

Effect: Allow or Deny
Action: What the principal can do (e.g., ec2:StartInstances)
Resource: What the action applies to

Example policy:

Allows all actions on a development EC2 instance
Denies tag creation and deletion

Account Alias

An account alias is a friendly name you can assign to your AWS account, making sign-in URLs more memorable than using your 12-digit AWS account ID.

Instead of:

https://88885770278076.signin.aws.amazon.com/console

You can use:

https://your-company.signin.aws.amazon.com/console

IAM Security Best Practices

Avoid using the root account for regular tasks
✅ Enable Multi-Factor Authentication (MFA) for all users
Follow the principle of least privilege—grant only the permissions necessary
Rotate access keys and passwords regularly
Use AWS CloudTrail to log and monitor activity
Use IAM roles for applications instead of hardcoding credentials

Common IAM Use Cases

Grant an EC2 instance access to read/write data in S3
Allow developers to deploy to Lambda but not modify billing settings
Share access between AWS accounts using cross-account roles
Integrate with corporate identity providers using SAML or Active Directory

Conclusion

IAM is at the heart of AWS security. By effectively managing identities and access, you can maintain strong security postures, minimize risks, and ensure only the right people (or systems) have access to the right resources at the right time.

Security in the cloud starts with smart IAM practices.

Coder Legion - Recent posts tagged cloud-security

EU's Controversial Chat Control Amendment Passed and Potential Security Implications

Scanning User Messages

How?

Technical Risks

AI False Positives and Bias

Scanning Tools

Average Users Think Messages Are Private

Alternative Solutions

There Is No Perfect Solution

Environmental Impact

Ethical Considerations

Alternative Solutions

Useful Sources

How Do You Protect Privacy & Security in Cloud Platforms Amid Encryption Risks and AI Threats?

Understanding Cloud Security with AWS Identity and Access Management (IAM)

What is AWS IAM?

Identities in IAM

Access Management

Tags

Key Components of IAM

IAM Users

IAM Groups

IAM Roles

IAM Policies

Account Alias

IAM Security Best Practices

Common IAM Use Cases

Conclusion