“The healer” su Thrill Jockey Records è il quinto disco sulla lunga distanza per i Sumac, gruppo di punta del rumorismo e della totale libertà musicale. Il gruppo formato da Nick Yacyshyn, Brian Cook e Aaron Turner torna a disegnare ardite parabole nei consumati cieli della musica moderna. @Musica Agorà

iyezine.com/sumac-the-healer

Sumac - The healer

Sumac - The healer - Sumac: una delle più particolari e meravigliose esperienze sonore che possiate compiere in questi tempi aridi. - Sumac

^{Massimo Argo (In Your Eyes ezine)}

I did something recently I haven’t done in a long time: I recompiled the Linux kernel. There was a time when this was a common occurrence. You might want a feature that the default kernel didn’t support, or you might have an odd piece of hardware. But these days, in almost all the cases where you need something like this, you’ll use loadable kernel modules (LKM) instead. These are modules that the kernel can load and unload at run time, which means you can add that new device or strange file system without having to rebuild or even restart the kernel.

Normally, when you write programs for Linux, they don’t have any special permissions. You typically can’t do direct port I/O, for example, or arbitrarily access memory. The kernel, however, including modules, has no such restriction. That can make debugging modules tricky because you can easily bring the system to its knees. If possible, you might think about developing on a virtual machine until you have what you want. That way, an errant module just brings down your virtual machine.

History

Some form of module support has been around since Linux 1.2. However, modern kernels can be built to include support for things or support them as modules. For example, you probably don’t want to put drivers for every single known video card in your kernel. But it is perfectly fine to build dozens or hundreds of modules you might need and then load the one you need at run time.

LKMs are at the heart of device drivers, file system drivers, and network drivers. In addition, modules can add new system calls, override existing system calls, add TTY line disciplines, and handle how executables run.

In Use

If you want to know what modules you have loaded, that’s the lsmod command. You’ll see that some modules depend on other modules and some don’t. There are two ways to load modules: insmod and modprobe. The insmod command simply tries to load a module. The modprobe command tries to determine if the module it is loading needs other modules and picks them up from a known location.

You can also remove modules with rmmod assuming they aren’t in use. Of course, adding and removing modules requires root access. You can usually run lsmod as a normal user if you like. You might also be interested in depmod to determine dependencies, and modinfo which shows information about modules.

Writing a Module

It is actually quite easy to write your own module. In fact, it is so simple that the first example I want to look at is a little more complex than necessary.

This simple module can load and unload. It leaves a message in the system messages (use dmesg, for example) to tell you it is there. In addition, it allows you to specify a key (just an arbitrary integer) when you load it. That number will show up in the output data. Here’s the code:
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/printk.h>

MODULE_AUTHOR("Al Williams");
MODULE_DESCRIPTION("Hackaday LKM");
MODULE_LICENSE("GPLv2"); // many options, GPL, GPLv2, Proprietary, etc.

static int somedata __initdata=0xbeef; // this is just some static variable available only at init
static int key=0xAA; // you can override this using insmod
// Note 0644 means that the sysfs entry will be rw-r--r--
module_param(key,int,0644); // use module_param_named if you want different names internal vs external
MODULE_PARM_DESC(key,"An integer ID unique to this module");

static int __init had_init(void)
{
// This is the usual way to do this (don't forget \n and note no comma after KERN_INFO), but...
printk(KERN_INFO "Hackaday is in control (%x %x)\n",key,somedata);
return 0;
}

static void __exit had_exit(void)
{
// ... you can also use the pr_info macro which does the same thing
pr_info("Returning control of your system to you (%x)!\n",key);
}

module_init(had_init);
module_exit(had_exit);</pre>

This isn’t hard to puzzle out. Most of it is include files and macros that give modinfo something to print out. There are some variables: somedata is just a set variable that is readable during initialization. The key variable has a default but can be set using insmod. What’s more, is because module_param specifies 0644 — an octal Linux permission — there will be an entry in the /sys/modules directory that will let the root set or read the value of the key.

At the end, there are two calls that register what happens when the module loads and unloads. The rest of the code is just something to print some info when those events happen.

I printed data in two ways: the traditional printk and using the pr_info macro which uses printk underneath, anyway. You should probably pick one and stick with it. I’d normally just use pr_info.

Building the modules is simple assuming you have the entire build environment and the headers for the kernel. Here’s a simple makefile (don’t forget to use tabs in your makefile):
<pre>obj-m += hadmod1.o

PWD := $(CURDIR) # not needed in most cases, but useful if using sudo

all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean</pre>

Once you build things, you should have a .ko file (like hadmod.ko). That’s the module. Try a few things:

1. sudo insmod hadmod.ko # load the module
2. sudo dmesg # see the module output
3. cat /sys/modules/hadmodule/key # see the key (you can set it, too, if you are root)
4. sudo rmmod hadmod.ko # unload the module
5. sudo insmod hadmod.ko key=128 # set key this time and repeat the other steps

That’s It?

That is it. Of course, the real details lie in how you interact with the kernel or hardware devices, but that’s up to you. Just to give a slightly meatier example, I made a second version of the module that adds /proc/jollywrencher to the /proc filesystem. Here’s the code:
#include <linux/init.h>
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/printk.h>
#include <linux/uaccess.h>
#include <linux/fs.h>
#include <linux/proc_fs.h> // Module metadata
#include <linux/version.h>

MODULE_AUTHOR("Al Williams");
MODULE_DESCRIPTION("Hackaday LKM1");
MODULE_LICENSE("GPLv2"); // many options, GPL, GPLv2, Proprietary, etc.

static char logo[]=
" \n"\
" \n"\
" \n"\
" #@@@@@@ ,@@@@@@ \n"\
" &@@@@@* &@@@@@, \n"\
" @@@@@@% @@@@@@# \n"\
" @@ .@@@@@@@@@ .@@@@@@@@@ .@# \n"\
" &@@@& /@@@@@@@@@@@@ @@@@@@@@@@@@ @@@@* \n"\
" @@@@@@@@@@@@@@@@@@@@@# @@@@@@@@@@@@@@@@@@@@@, \n"\
" &@@@@@@@@@@@@@@@@@@@@@* ,@@@@@@@@@@@@% &@@@@@@@@@@@@@@@@@@@@@* \n"\
" ,*. @@@@@@@@@@@/ .@@@@@@@@@@@@@@@@@@@@& &@@@@@@@@@@# ** \n"\
" @@@@@@, &@@@@@@@@@@@@@@@@@@@@@@@@@, %@@@@@& \n"\
" ,@& /@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@ \n"\
" &@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@* \n"\
" %@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@. \n"\
" @@@@@@ #@@@@@@@. /@@@@@@ \n"\
" /@@@@& @@@@@@. @@@@@ \n"\
" ,@@@@% (@@@@@@@@@@&* @@@@@ \n"\
" @@@@@# @@@@@@@@@@@@@@@@@@% @@@@@& \n"\
" /@@@@@@@@@@@@@@@, #@@@@@@@@@@@@@@@ \n"\
" @@ *@@@@@@@@@@@@@& ( @@@@@@@@@@@@@@ .@( \n"\
" %@@@@@. @@@@@@@@@@@@@@@@@@@@@@@@@@@@% #@@@@@* \n"\
" (%&%((@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@@@@@% ,@@@@@@@@@@*#&/ \n"\
" @@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@( @@@@@@@@@@@@@@@@@@@@@& \n"\
" @@@@@@@@@@@@@@@@@@@@@ @@@@@@*@@@@@@/%@@@@@& *@@@@@@@@@@@@@@@@@@@@# \n"\
" @@@@. @@@@@@@@@@@. .. . . (@@@@@@@@@@# /@@@* \n"\
" @, %@@@@@@@@ .@@@@@@@@. \n"\
" ,@@@@@( @@@@@@ \n"\
" *@@@@@@ (@@@@@@ \n"\
" @@@@@@, %@@@@@@ \n"\
" \n"\
" ";

static struct proc_dir_entry *proc_entry;
static ssize_t had_read(struct file *f, char __user * user_buffer, size_t count, loff_t * offset)
{
size_t len;
if (*offset>0) return 0; // no seeking, please!
copy_to_user(user_buffer,logo,len=strlen(logo)); // skipped error check
*offset=len;
return len;
}

#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,6,0)
static struct proc_ops procop = // prior to Linux 5.6 you needed file_operations
{
.proc_read=had_read
};
#else
static struct file_operations procop =
{
.owner=THIS_MODULE,
.read=had_read
#endif

static int __init had_init(void)
{
// This is the usual way to do this (don't forget \n and note no comma after KERN_INFO), but...
printk(KERN_INFO "Hackaday<1>; is in control\n");
proc_entry=proc_create("jollywrencher",0644,NULL,&procop);
return 0;
}

static void __exit had_exit(void)
{
// ... you can also use the pr_info macro which does the same thing
pr_info("Returning control of your system to you...\n");
proc_remove(proc_entry);
}

module_init(had_init);
module_exit(had_exit);

The only thing here is you have an extra function that you have to register and deregister with the kernel. However, that interface changed in Kernel 5.6, so the code tries to do the right thing. Until, of course, it gets changed again.

Once you load this module using insmod, you can cat /proc/jollywrencher to see your favorite web site’s logo.

Of course, this is a dead simple example, but it is enough to get you started. You can grab all the source code online. One great way to learn more is to find something similar to what you want to build and take it apart.

We don’t suggest it, but you can write an LKM in Scratch. If you really want to learn the kernel, maybe start at the beginning.

VMware ha risolto una serie di vulnerabilità critiche in vCenter Server, tra cui l’esecuzione di codice in modalità remota e l’escalation dei privilegi locali.

Gli sviluppatori hanno fornito correzioni per tre problemi contemporaneamente: CVE-2024-37079, CVE-2024-37080, CVE-2024-37081.

• CVE-2024-37079 : una vulnerabilità critica di heap overflow nell’implementazione del protocollo DCERPC in vCenter Server che consente a un utente malintenzionato con accesso alla rete di inviare pacchetti appositamente predisposti e potrebbe potenzialmente portare all’esecuzione di codice in modalità remota (punteggio CVSS 9,8).
• CVE-2024-37080 : un altro problema critico di heap overflow nel protocollo vCenter Server DCERPC. Come CVE-2024-37079, consente a un utente malintenzionato con accesso alla rete di sfruttare un overflow dell’heap inviando pacchetti modificati, che possono portare all’esecuzione di codice remoto (punteggio CVSS 9,8).
• CVE-2024-37081 : esiste una vulnerabilità dovuta a un’errata configurazione di sudo in vCenter Server, che consente a un utente locale autenticato di sfruttare il bug per aumentare i propri privilegi a root (7.8 sulla scala CVSS).

Gli errori elencati riguardano VMware vCenter Server versioni 7.0 e 8.0, nonché VMware Cloud Foundation versioni 4.x e 5.x.

Le patch per VMware vCenter Server erano incluse nelle versioni 8.0 U2d, 8.0 U1e e 7.0 U3r. E per Cloud Foundation, sono state aggiunte correzioni in KB88287.

Secondo il produttore non esistono contromisure alternative efficaci per queste vulnerabilità, pertanto si consiglia a tutti gli utenti di installare gli ultimi aggiornamenti il ​​prima possibile.

L'articolo VMware vCenter Server: 2 RCE da 9,8 di score e una Privilege Escalation da Patchare subito proviene da il blog della sicurezza informatica.

La potenza dei computer moderni continua a crescere, rendendo possibile la risoluzione più rapida di problemi sempre più complessi. Uno degli effetti collaterali di questo fenomeno è la possibilità di hackerare quelle password che solo pochi anni fa sembravano ineludibili.

Un recente studio di Kaspersky Lab ha scoperto che una scheda grafica RTX 4090 può indovinare una password di otto cifre composta da lettere e numeri in soli 17 secondi. E oltre la metà di tutte le password utilizzate nel cyberspazio (59%) possono essere violate in meno di un’ora.

Per autenticare gli utenti, i siti Web memorizzano le coppie login-password come hash anziché in testo non crittografato. Gli hash proteggono le password in caso di perdite aggiungendo un salt prima dell’hash per impedire l’uso delle rainbow table. Nonostante l’irreversibilità degli hash, un utente malintenzionato che riesce ad accedere a un database trapelato può provare a indovinare le password utilizzando strumenti già pronti, che sono disponibili pubblicamente.

Lo studio ha analizzato 193 milioni di password trapelate disponibili su vari siti del dark web. Le password non sono state raccolte o archiviate da Kaspersky Lab stessa. Sono stati utilizzati vari algoritmi per stimare il tempo necessario per decifrare una password utilizzando metodi di forza bruta, inclusi attacchi a dizionario e attacchi di forza bruta su combinazioni di caratteri comuni.

Il metodo della forza bruta è semplice e diretto: il computer prova tutte le password possibili finché non trova quella corretta. Questo approccio è meno efficace per le password lunghe. Il tempo di cracking dipende direttamente dalla lunghezza della password e dal numero di tipi di caratteri in essa contenuti.

Le password più popolari (28%) includono lettere maiuscole, caratteri speciali e numeri. La maggior parte di queste password sono difficili da decifrare utilizzando metodi di forza bruta: circa il 5% può essere indovinato in un solo giorno, ma il restante 85% impiega più di un anno per indovinarlo.

Le password che contengono solo lettere, numeri o caratteri speciali sono le meno forti. La maggior parte di queste password può essere violata entro un giorno. Le statistiche hanno mostrato che le password complesse costituite solo da lettere iniziavano con 11 caratteri, mentre nel campione non c’erano password complesse costituite solo da numeri.

Esistono algoritmi che ottimizzano il processo di hacking, tenendo conto delle combinazioni di caratteri più comuni come “12345” o “qwerty”. Ad esempio, l’algoritmo zxcvbn stima la complessità di una password determinandone lo schema e calcolando il numero di iterazioni necessarie per decifrarla.

Lo studio ha utilizzato vari algoritmi ottimizzati come 3gram_seq e ngram_opt_corr. Questi metodi tengono conto della probabilità che i caratteri successivi appaiano in base a quelli precedenti. Gli algoritmi ottimizzati possono fornire un vantaggio significativo nella velocità di hacking.

Dallo studio è emerso che il 45% di tutte le password può essere indovinato in meno di un minuto, il 59% in meno di un’ora e il 73% in meno di un mese. E solo il 23% delle password impiega più di un anno per essere decifrate.

La maggior parte (57%) delle password contiene una parola del dizionario, il che ne riduce notevolmente la forza. La metà di queste password può essere violata in meno di un minuto e il 67% in meno di un’ora. Solo il 12% di queste password sono abbastanza forti.

Le GPU moderne sono in grado di decifrare le password a una velocità incredibile. Per proteggere i tuoi account, ti consigliamo di utilizzare password casuali generate dal computer. Altrimenti si consiglia di utilizzare password lunghe che comprendano lettere maiuscole e minuscole, numeri e caratteri speciali, evitando le parole del dizionario.

Inoltre, è una buona idea controllare la robustezza delle tue password utilizzando strumenti specializzati. Se mostrano che la tua password è debole, dovresti cambiarla. Inoltre, su tutti gli account importanti deve essere configurata l’autenticazione a due fattori, in modo che anche se la tua password viene rubata o indovinata, gli hacker non saranno in grado di accedere ai tuoi dati.

Inoltre, e non ci stancheremo mai di dirlo, l’utilizzo della Multi Factor Authentication ove sia possibile, risulta sempre la scelta più saggia oggi.

L'articolo Password senza Futuro! Le nuove GPU aprono il 59% di tutte le Password del Web in meno di un’ora proviene da il blog della sicurezza informatica.

The Frame AR glasses by Brilliant Labs, which contain a small display, are an entirely different approach to hacker-accessible and affordable AR glasses. [Karl Guttag] has shared his thoughts and analysis of how the Frame glasses work and are constructed, as usual leveraging his long years of industry experience as he analyzes consumer display devices.

It’s often said that in engineering, everything is a tradeoff. This is especially apparent in products like near-eye displays, and [Karl] discusses the Frame glasses’ tradeoffs while comparing and contrasting them with the choices other designs have made. He delves into the optical architecture, explaining its impact on the user experience and the different challenges of different optical designs.

The Frame glasses are Brilliant Labs’ second product with their first being the Monocle, an unusual and inventive sort of self-contained clip-on unit. Monocle’s hacker-accessible design and documentation really impressed us, and there’s a pretty clear lineage from Monocle to Frame as products. Frame are essentially a pair of glasses that incorporate a Monocle into one of the lenses, aiming to be able to act as a set of AI-empowered prescription glasses that include a small display.

We recommend reading the entire article for a full roundup, but the short version is that it looks like many of Frame’s design choices prioritize a functional device with low cost, low weight, using non-specialized and economical hardware and parts. This brings some disadvantages, such as a visible “eye glow” from the front due to display architecture, a visible seam between optical elements, and limited display brightness due to the optical setup. That being said, they aim to be hacker-accessible and open source, and are reasonably priced at 349 USD. If Monocle intrigued you, Frame seems to have many of the same bones.

Un attore di minacce, noto come IntelBroker, ha affermato di aver ottenuto e messo in vendita dati rubati da Apple. Questi dati includono il codice sorgente di tre strumenti utilizzati all’interno del sito web di Apple.

IntelBroker è attivo nel dark web ed è associato a un gruppo chiamato CyberNiggers. È specializzato nella vendita di accessi a sistemi compromessi e ha condotto attacchi contro aziende importanti come Zscaler ed Europol. IntelBroker opera su forum underground come XSS, Breachforums ed Exposed, dove vende dati sensibili a prezzi sorprendentemente bassi. Inoltre, sviluppa ransomware e si è distinto per la sua abilità nel compromettere sistemi di alto profilo, agendo come intermediario per l’accesso iniziale ai sistemi (Initial Access Broker).

Secondo IntelBroker, la violazione ha portato alla compromissione delle seguenti informazioni, utilizzate all’interno del sito web di Apple:

• AppleConnect-SSO

AppleConnect-SSO (Single Sign-On) è un sistema di autenticazione sviluppato da Apple che consente agli utenti di accedere a diverse applicazioni e servizi utilizzando un unico set di credenziali.

Questo strumento è particolarmente utile per le organizzazioni che utilizzano numerosi servizi Apple, poiché riduce la necessità di gestire più password e semplifica il processo di accesso.

• Apple-HWE-Confluence-Advanced

Apple-HWE-Confluence-Advanced è uno strumento avanzato di gestione della documentazione e collaborazione basato su Confluence, una piattaforma ampiamente utilizzata per la gestione della conoscenza e la collaborazione tra team. Questo strumento è personalizzato per soddisfare le esigenze specifiche dell’ambiente hardware di Apple (HWE – Hardware Engineering), offrendo funzionalità avanzate per la gestione dei progetti, la documentazione tecnica e la collaborazione tra i team.

• AppleMacroPlugin

AppleMacroPlugin è un plugin sviluppato per migliorare l’efficienza e l’automazione dei processi all’interno delle applicazioni Apple. Questo plugin consente agli utenti di creare e utilizzare macro, ossia sequenze registrate di comandi e azioni, per automatizzare attività ripetitive e complesse. È uno strumento prezioso per gli utenti avanzati che desiderano ottimizzare il loro flusso di lavoro e risparmiare tempo.

Le attività di IntelBroker rappresentano una seria minaccia per la sicurezza informatica, mettendo in evidenza come anche le grandi aziende tecnologiche come Apple possano essere vulnerabili agli attacchi informatici.

L'articolo IntelBroker Colpisce Ancora! Mette in vendita il codice di Apple nell’underground criminale proviene da il blog della sicurezza informatica.

This is the Central Scrutinizer...
It is my responsibility to enforce all the laws
That haven't been passed yet
It is also my responsibility to alert each
And every one of you to the potential consequences
Of various ordinary everyday activities
You might be performing which could eventually lead to
The Death Penalty (or affect your parents' credit rating)
Our criminal institutions are full of little creeps
Like you who do wrong things...
And many of them were driven to these crimes
By a horrible force called music!

Our studies have shown that this horrible force
Is so dangerous to society at large that laws
Are being drawn up at this very moment to stop it forever!
Cruel and inhuman punishments are being carefully described
In tiny paragraphs so they won't conflict with the Constitution
(Which, itself, is being modified in order to accommodate the future)

I bring you now a special presentation
To show what can happen to you if you choose a career in music...
The white zone is for loading and unloading only...
If you have to load or unload, go to the white zone...
You'll love it... it's a way of life... Ha, ha, ha, ha, ha...
Hi, it's me, I'm back
This is the Central Scrutinizer...
The white zone is for loading and unloading only...
If yah gotta load, or if yah gotta unload, go to the white zone
You'll love it... it's a way of life
That's right, you'll love it, it's a way of life
That's right, you'll love it, it's a way of life
You'll love it
This, is, the Central Scrutinizer!
- Frank Zappa

iv.datura.network/watch?v=IgG8…

The following letter by Members of Parliament from across the EU has been sent today (and is still open for signatures):

Dear Council of the European Union,
Dear national governments,

In the last days of the Belgian EU Council Presidency, Belgium has put forward its final initiative to reach a general approach in the Council of the EU regarding the highly contested CSA regulation (Proposal for a regulation of the European Parliament and of the Council laying down rules to prevent and combat child sexual abuse). In possibly putting the CSA Regulation to a vote on 19 June, the Council is risking far more than just passing a simple regulation.

Sexual abuse and the exploitation of children, including the dissemination of child sexual abuse material, must be addressed with the utmost determination in accordance with the rule of law. While the regulation proposal put forward by the EU Commission includes some good and crucial measures, such as the EU center, it is highly questionable whether core aspects of the regulation are compatible with European fundamental rights.

As parliamentarians, we observe with great concern the proposal of the Council of the EU that would put to an end the confidentiality of private communication. Even if the Belgian Council Presidency has now presented a compromise proposal that would limit the obligation to scanning private unencrypted as well as encrypted video and image content, it remains just as much an encroachment on fundamental digital rights and takes the discussion back to the origin of the debate. In fact, the Belgian proposal represents the Commission’s first plans that came to light in December 2021.

Safe and encrypted communication is of utmost importance for every human being. This also accounts for children and victims of sexual abuse to allow for safe emergency and help services – particularly in countries where victim support organisations cannot rely on the support and confidentiality of state law enforcement authorities.

Besides risking to contradict the aim of the CSA proposal by intervening in the digital self-determination of people, there might be several unintentional but dangerous side effects:

• Client Side Scanning (CSS) and any other mass surveillance, would render confidential information carriers impossible: Scanning would affect users who rely on confidential communication and whose communication is particularly protected (professionals bound by confidentiality such as journalists, lawyers, the medical sector, but also whistleblowers). Furthermore, built-in backdoors could compromise the confidentiality of digitally transmitted trade secrets and business transactions. Encryption protects the identity and the contents of communication participants, thus preserving the autonomy of victims of sexual violence.
• Democratic society and democratic debate need trustworthy spaces: Democratic societies need privacy for the formation of opinions and will. The proposed measures carry the danger of leading to self-censorship, jeopardizing safe spaces for children and victims of sexual violence, but also for everyone else. It will also likely leave to users unwilling to use digital services and lose trust in providers if their data is not secure and protected.
• Blueprint for authoritarian states and weakening cybersecurity: By building an architecture capable of undermining all possibility of private digital communication, the regulation might inadvertently serve as a blueprint for surveillance in authoritarian states and can serve as a built-in backdoor that can easily be exploited for all sorts of surveillance practices (e.g. trade secrets) and cybercriminals. Once built, this IT-architecture is an invitation to undermine privacy.
• Impairment of digital educational, youth, and assistance services: It will eliminate the common practice to exchange important sexual health information to such education as is case in some European countries.

The mandatory investigation of private communication messages without suspicion carries the risk of creating a climate of general suspicion. Such an approach will irreparably damage the image of the European Union as a guarantor of freedom.

We explicitly warn that the obligation to systematically scan encrypted communication, whether called “upload-moderation” or “client-side scanning”, would not only break secure end-to-end encryption, but will to a high probability also not withstand the case law of the European Court of Justice. Rather, such an attack would be in complete contrast to the European commitment to secure communication and digital privacy, as well as human rights in the digital space.

We therefore urgently need an approach that prioritizes the protection and prevention of child sexual abuse, provides more resources and better-targeted coordination of European law enforcement authorities, strengthens victim support in accordance with fundamental rights, and avoids relying on a false sense of security through technosolutionism.

As national and European parliamentarians, we are convinced that the proposed measures are incompatible with European fundamental rights. We are committed to safeguarding the right to anonymous and pseudonymous use of the internet, as well as strengthening end-to-end encryption.

We urgently call on all negotiating governments in the COREPER to reject a general approach based on compromise proposal that Belgium has put forward.

Signatories

Tobias B. Bacherle, MP, Alliance 90/The Greens, Germany

Konstantin von Notz, MP & Vice Chair of the group, Alliance 90/The Greens, Germany

Süleyman Zorba, MP, The Greens, Austria

Maximilian Funke-Kaiser, MP, FDP, Germany

Konstantin Kuhle, MP & Vice Chair of the group, FDP, Germany

Sven Clement, MP, Pirates, Luxembourg

Patrick Breyer, MEP, Pirates, Germany

Marketa Gregorová, MEP, Pirates, Czech Republic

Marcel Kolaja, MEP, Pirates, Czech Republic

Rasmus Andresen, MEP, Alliance 90/The Greens, Germany

Maik Außendorf, MP, Alliance 90/The Greens, Germany

Michael Bloss, MEP, Alliance 90/The Greens, Germany

Damian Boeselager, MEP, Volt, Germany

Georg Bürstmayr, MP, The Greens, Austria

Marcel Emmerich, MP, Alliance 90/The Greens, Germany

Emilia Fester, MP, Alliance 90/The Greens, Germany

Alexandra Geese, MEP, Alliance 90/The Greens, Germany

Stefan Gelbhaar, MP, Alliance 90/The Greens, Germany

Andreas Glück, MEP, FDP, Germany

Sabine Grützmacher, MP, Alliance 90/The Greens, Germany

Svenja Hahn, MEP, FDP, Germany

Katrin Helling-Plahr, MP, FDP, Germany

Manuel Höferlin, MP, FDP, Germany

Misbah Khan, MP, Alliance 90/The Greens, Germany

Moritz Körner, MEP, FDP, Germany

Katharina Kucharowits, MP, SPÖ, Austria

Denise Loop, MP, Alliance 90/The Greens, Germany

Boris Mijatovic, MP, Alliance 90/The Greens, Germany

Maximilian Mordhorst, MP, FDP, Germany

Hannah Neumann, MEP, Alliance 90/The Greens, Germany

Dr. Nikolaus Scherak, MP, NEOS, Austria

Jan-Christoph Oetjen, MEP, FDP, Germany

Tabea Rößner, MP, Alliance 90/The Greens, Germany

Michael Sacher, MP, Alliance 90/The Greens, Germany

Kordula Schulz-Asche, MP, Alliance 90/The Greens, Germany

Kim van Sparrentak, MEP, Greens, Netherlands

Marie-Agnes Strack-Zimmermann, MP, FDP, Germany

Council is to greenlight #Chatcontrol 2.0 on Thursday!

Don‘t let them get away with quietly pushing this through right after the #EuropeanElections. Sound the alarm and contact the representatives of your government NOW! Contact details and additional informationContact details and additional information

Contact details and additional information

patrick-breyer.de/en/lawmakers…