Spcnet.it

2026-05-05 08:46:50

Jenkins Secret Guard Plugin: blocca i segreti hardcoded nelle pipeline CI/CD

I segreti hardcoded nelle pipeline Jenkins sono uno dei problemi di sicurezza più sottovalutati nell’ecosistema CI/CD. Token API incollati direttamente in un campo di configurazione durante un test rapido, URL di webhook con query parameter segreti rimasti nel config.xml, header di autorizzazione in Jenkinsfile scritti una volta e mai più rivisti: situazioni ordinarie che, però, aprono falle di sicurezza concrete e difficili da intercettare manualmente.

Il nuovo Secret Guard Plugin per Jenkins è stato creato esattamente per risolvere questo problema: un plugin focalizzato, deterministico e pronto per ambienti di produzione che analizza le configurazioni Jenkins e le Pipeline alla ricerca di pattern ad alto rischio di esposizione di segreti.

Cosa analizza Secret Guard

Il plugin esamina le posizioni più comuni dove i segreti finiscono per errore:

• File config.xml dei job
• Script Pipeline inline
• Jenkinsfile recuperati da SCM (quando è disponibile l’accesso SCM leggero)
• Valori di default dei parametri
• Definizioni di variabili d’ambiente
• Contenuto di comandi come sh, bat, powershell e chiamate HTTP

L’approccio è intenzionalmente stretto nel perimetro: Secret Guard non cerca di essere uno strumento di governance generalista né un analizzatore di qualità del codice. Si concentra su pattern ad alta confidenza e ben documentati, riducendo il rumore prodotto da euristiche troppo aggressive.

Un esempio pratico

Il caso più frequente è una Pipeline che incorpora un token direttamente in una variabile d’ambiente o in un header HTTP. Ecco un Jenkinsfile problematico:

pipeline {
    agent any
    environment {
        API_TOKEN = 'ghp_012345678901234567890123456789012345'
    }
    stages {
        stage('Call API') {
            steps {
                sh "curl -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.abc123456789' https://api.example.com"
            }
        }
    }
}

Una volta che questo segreto è memorizzato nella configurazione del job, diventa difficile da ruotare e facile da esporre tramite export, backup, log o screenshot. Secret Guard rileva questi pattern prima che diventino un problema.

Il pattern corretto prevede di archiviare il segreto nelle Jenkins Credentials e iniettarlo solo a runtime:

pipeline {
    agent any
    stages {
        stage('Call API') {
            steps {
                withCredentials([string(credentialsId: 'api-token', variable: 'API_TOKEN')]) {
                    sh 'curl -H "Authorization: Bearer $API_TOKEN" https://api.example.com'
                }
            }
        }
    }
}

Con questo approccio, il valore del token non compare mai nel codice sorgente né nella configurazione del job: viene risolto da Jenkins solo al momento dell’esecuzione e mascherato automaticamente nei log.

Modalità di utilizzo

Secret Guard può essere usato in diversi contesti pratici:

• Enforcement al salvataggio: blocca o segnala configurazioni di job che introducono segreti hardcoded nel momento in cui vengono salvate
• Scansione a runtime: analizza la Pipeline durante l’esecuzione del build
• Scan a livello di job: tramite l’azione “Scan Now” disponibile sulla pagina del job
• Scan globale: la pagina amministrativa “Secret Guard” permette di analizzare tutti i job con un solo click

I risultati vengono archiviati in forma mascherata: gli amministratori possono esaminare i findings senza che i valori raw vengano persistiti nei report del plugin.

Tre livelli di enforcement

Per consentire un’adozione graduale, il plugin supporta tre modalità configurabili:

• AUDIT: registra i findings senza bloccare nulla, ideale come punto di partenza per capire la situazione attuale
• WARN: l’operazione viene completata ma il rischio viene segnalato esplicitamente
• BLOCK: impedisce il salvataggio o l’esecuzione quando vengono trovati findings non esentati al di sopra della soglia configurata

Questa progressione permette di partire con la visibilità (AUDIT) e spostarsi verso un enforcement più rigoroso man mano che i team sanano i problemi esistenti.

Installazione

Il plugin è disponibile nel Jenkins Plugin Manager con il nome secret-guard. L’installazione è standard: Manage Jenkins → Plugins → Available plugins → cerca “Secret Guard”. Dopo il riavvio, la pagina “Secret Guard” apparirà nel menu di amministrazione globale.

Conclusione

Secret Guard colma un gap reale nelle pipeline Jenkins: la mancanza di uno strumento specifico, leggero e a basso rumore per intercettare i segreti hardcoded prima che finiscano in backup, log o nelle mani sbagliate. L’approccio deterministico — in contrapposizione all’inferenza AI o alle euristiche generiche — lo rende particolarmente adatto agli ambienti di produzione dove la prevedibilità del comportamento è critica.

Per team che già usano Jenkins in modo intensivo, introdurlo in modalità AUDIT per qualche settimana prima di passare a WARN o BLOCK è la strategia più sicura per ottenere subito visibilità senza interrompere i workflow esistenti.

Fonte: Introducing the Secret Guard Plugin – Jenkins Blog

Introducing the Secret Guard Plugin

A Jenkins plugin that checks Jenkins job configuration and Pipeline definitions for hardcoded secret leakage risks.

^{Introducing the Secret Guard Plugin}

Spcnet.it

2026-05-05 08:48:09

Gemma 4 con Ollama e .NET Aspire: LLM in locale con il visualizzatore GenAI completo

Se hai già usato l’integrazione Azure Foundry o Azure OpenAI in .NET Aspire, conosci già quella funzionalità: il visualizzatore GenAI che mostra le conversazioni con il modello all’interno del dashboard di tracing. Fai clic su una traccia, scorri fino alla chiamata LLM, e appare una piccola icona “sparkles”. Cliccandola, si apre un pannello con il log completo: system prompt, messaggio utente, risposta del modello, tool call, conteggio token e finish reason.

A prima vista sembra una funzionalità esclusiva di Azure Foundry. Non lo è. Il dashboard Aspire non controlla se gen_ai.system == "openai" né fa chiamate ad Azure. Si basa sulle OpenTelemetry GenAI semantic conventions: qualsiasi backend che emette span gen_ai.* con la forma corretta ottiene lo stesso trattamento. Ollama, LM Studio, llama.cpp — se espone un’API compatibile con OpenAI Chat Completions, può illuminare lo stesso popup.

Questo articolo mostra come configurare Ollama con il modello Gemma 4 in locale e ottenere il visualizzatore GenAI completo nel dashboard Aspire, senza Azure e senza costi cloud.

Perché eseguire LLM in locale?

I motivi sono diversi a seconda del contesto:

• Compliance e data privacy: i dati non escono dall’infrastruttura aziendale.
• Costi prevedibili: niente fatture cloud che raddoppiano durante i picchi di sviluppo AI.
• Sviluppo offline: il modello funziona anche senza connessione Internet.
• Iterazione rapida: nessun rate limit durante i test intensivi.

Il meccanismo: OpenTelemetry GenAI conventions

Il dashboard Aspire renderizza il visualizzatore GenAI quando trova span con questi attributi OpenTelemetry:

• gen_ai.operation.name (es. chat, embedding)
• gen_ai.request.model — il modello richiesto
• gen_ai.response.model — il modello che ha risposto
• gen_ai.input.messages — il prompt, serializzato in JSON
• gen_ai.output.messages — la risposta, serializzata in JSON
• gen_ai.usage.input_tokens / gen_ai.usage.output_tokens
• gen_ai.response.finish_reasons

Quando uno span con questi attributi appare nella vista traces sull’activity source Experimental.Microsoft.Extensions.AI, il dashboard aggiunge l’icona sparkles e mostra il popup.

IChatClient è l’astrazione di Microsoft.Extensions.AI per qualsiasi cosa a cui si possano inviare messaggi chat. Azure OpenAI, Ollama e i modelli locali la implementano direttamente o si adattano ad essa. Il wrapper OpenTelemetry che ci interessa sa solo come tracciare oggetti con la forma di IChatClient.

Le quattro cose da configurare

Per ottenere il visualizzatore GenAI con un modello locale servono esattamente quattro elementi:

1. Un’integrazione di hosting che esegue il backend del modello come risorsa Aspire e produce una connection string.
2. Un IChatClient nel servizio consumer, decorato con UseOpenTelemetry() e content capture abilitato.
3. La registrazione della sorgente di tracing in ServiceDefaults per far fluire gli span GenAI nel tracer provider.
4. Il toggle di content capture, tramite variabile d’ambiente o via UseOpenTelemetry. Senza di esso il popup appare ma i messaggi sono vuoti.

Mancarne anche solo uno produce output silenziosamente degradato: senza il punto 3 gli span non escono dal processo; senza il punto 4 il popup è vuoto; senza il punto 2 si ottengono solo span HTTP generici.

1. Integrazione hosting: Ollama come risorsa Aspire

Aspire non include un’integrazione Ollama out of the box. Il Community Toolkit ne ha una, ma costruirla da zero mostra il pattern applicabile a qualsiasi backend OpenAI-compatible.

In una nuova class library referenziata dall’AppHost (con il package Aspire.Hosting):

public sealed class OllamaResource(string name)
    : ContainerResource(name), IResourceWithConnectionString
{
    internal const string PrimaryEndpointName = "http";
    private EndpointReference? _primaryEndpoint;

    public EndpointReference PrimaryEndpoint =>
        _primaryEndpoint ??= new EndpointReference(this, PrimaryEndpointName);

    public ReferenceExpression ConnectionStringExpression =>
        ReferenceExpression.Create(
            $"Endpoint={PrimaryEndpoint.Property(EndpointProperty.Url)}");
}

public static class OllamaResourceBuilderExtensions
{
    public static IResourceBuilder<OllamaResource> AddOllama(
        this IDistributedApplicationBuilder builder,
        string name,
        int? port = null)
    {
        var resource = new OllamaResource(name);
        return builder.AddResource(resource)
            .WithImage("ollama/ollama", "latest")
            .WithHttpEndpoint(port: port ?? 11434, targetPort: 11434, 
                             name: OllamaResource.PrimaryEndpointName)
            .WithVolume("ollama-data", "/root/.ollama");
    }
}

Nell’AppHost si aggiunge la risorsa Ollama e si collega al servizio che la usa:

var ollama = builder.AddOllama("ollama")
    .WithModel("gemma4:e2b");

var api = builder.AddProject<Projects.ScrumSummary_Api>("api")
    .WithReference(ollama)
    .WaitFor(ollama);

2. IChatClient con OpenTelemetry nel servizio consumer

Nel servizio che usa il modello, si registra il client con la catena di decoratori corretta:

builder.Services.AddSingleton(sp =>
{
    var connectionString = builder.Configuration.GetConnectionString("ollama")!;
    var endpoint = new Uri(connectionString.Replace("Endpoint=", ""));

    return new OllamaApiClient(endpoint)
        .AsChatClient("gemma4:e2b")
        .AsBuilder()
        .UseOpenTelemetry(configure: options =>
        {
            // Abilita la cattura del contenuto dei messaggi
            options.EnableSensitiveData = true;
        })
        .Build();
});

Il flag EnableSensitiveData = true è il toggle critico. Senza di esso, il popup nel dashboard compare ma non mostra i messaggi (per motivi di privacy è disabilitato di default).

3. Registrazione della sorgente di tracing in ServiceDefaults

Nel progetto ServiceDefaults, aggiungere la sorgente activity di Microsoft.Extensions.AI:

builder.Services.AddOpenTelemetry()
    .WithTracing(tracing =>
    {
        tracing
            .AddAspNetCoreInstrumentation()
            .AddHttpClientInstrumentation()
            // Questa è la riga chiave
            .AddSource("Experimental.Microsoft.Extensions.AI");
    });

Senza questa riga gli span GenAI vengono emessi ma non raggiungono l’exporter e non appaiono nel dashboard.

4. Alternative al flag EnableSensitiveData

In ambienti dove non si vuole abilitare il flag nel codice (ad esempio per motivi di compliance), si può usare la variabile d’ambiente:

DOTNET_EXTENSIONS_AI_TELEMETRY_ENABLE_SENSITIVE_DATA=true

Oppure impostarla nell’AppHost solo per i progetti in development:

var api = builder.AddProject<Projects.ScrumSummary_Api>("api")
    .WithReference(ollama)
    .WithEnvironment("DOTNET_EXTENSIONS_AI_TELEMETRY_ENABLE_SENSITIVE_DATA", "true");

Il risultato nel dashboard

Una volta configurati tutti e quattro gli elementi, ogni chiamata al modello Ollama locale appare nelle traces di Aspire come span GenAI. Cliccando sull’icona sparkles si apre il pannello con il log completo della conversazione: system prompt, messaggi utente, risposta del modello con i token usati e il finish reason — esattamente come con Azure OpenAI o Azure Foundry, ma con il modello che gira sulla propria macchina.

Generalizzare ad altri backend

Il pattern si applica a qualsiasi backend compatibile con l’API OpenAI Chat Completions: LM Studio, llama.cpp con server HTTP, vLLM. L’unico requisito è che il client implementi o si adatti a IChatClient e che il wrapper UseOpenTelemetry() venga applicato. Il resto — la registrazione del tracing, il flag di content capture — rimane identico.

Conclusione

Il visualizzatore GenAI di .NET Aspire non è un’esclusiva di Azure. È un’interfaccia costruita sopra gli standard OpenTelemetry, accessibile a chiunque emetta gli span corretti. Quattro configurazioni, nessun servizio cloud obbligatorio, e si ottiene la stessa esperienza di debugging degli LLM che si avrebbe con Azure Foundry — con Gemma 4, Ollama e tutto in locale.

Fonte: Run Gemma 4 with Ollama locally, and keep the Aspire LLM Insights (sparkles and all) — Erik Lieben

Run Gemma 4 with Ollama locally, and keep the Aspire LLM Insights (sparkles and all)

Can't use Microsoft Foundry because of compliance or an Azure bill that doubles during an AI development spike, but still want the best AI debugging experience in Aspire? Here's how to keep the full GenAI chat-log sparkles while Ollama and Gemma 4 ru…

^{Erik Lieben}

Spcnet.it

2026-05-05 08:48:42

Fine del supporto NGINX Ingress su AKS: guida alla migrazione verso Gateway API

Se gestisci workload su Azure Kubernetes Service (AKS), nelle ultime settimane potresti aver ricevuto un’email da Microsoft che annuncia la fine del supporto per NGINX Ingress su AKS entro novembre 2026. Non si tratta di una comunicazione da ignorare: la migrazione è inevitabile e conviene pianificarla per tempo. In questo articolo vediamo cosa sta succedendo, perché è successo e cosa fare concretamente.

Il contesto: perché Ingress è diventato obsoleto

La risorsa Ingress di Kubernetes nasce con una specifica intenzionalmente minimale: regole di host e path, niente di più. Ma i load balancer cloud (AWS, Azure, GCP e altri) sono in grado di fare molto di più — timeout configurabili, retry policy, routing per header, circuit breaker — e gli utenti hanno cercato di esprimere queste funzionalità tramite annotation proprietarie sulle risorse Ingress. Il risultato è stato un’esplosione di annotation non standardizzate, specifiche per ogni controller, che rendono ogni configurazione di Ingress portabile solo sulla carta.

Gateway API è la risposta della community a questo problema. Sostituisce Ingress con risorse strutturate e tipizzate — HTTPRoute, Gateway, GatewayClass — capaci di esprimere comportamenti di routing avanzati in modo nativo e standardizzato, con una separazione netta tra il ruolo del platform team (che gestisce i Gateway) e il ruolo del team applicativo (che gestisce le HTTPRoute). Gateway API è stabile dalla versione 1.28 di Kubernetes ed è la direzione verso cui si sta muovendo l’intero ecosistema.

La fine di ingress-nginx e le conseguenze su AKS

Il progetto upstream ingress-nginx — il controller Ingress più diffuso nell’ecosistema Kubernetes — è stato formalmente ritirato a marzo 2026. Il progetto era mantenuto da un esiguo gruppo di volontari, aveva accumulato debito tecnico significativo e presentava vulnerabilità di sicurezza note rimaste senza patch. Con il ritiro, qualsiasi nuova vulnerabilità scoperta rimarrà indefinitamente senza correzione.

Microsoft ha fissato la propria data di fine supporto al novembre 2026, concedendo agli utenti AKS un margine aggiuntivo. Fino ad allora, le vulnerabilità critiche continueranno a essere corrette, ma non ci sarà sviluppo di nuove funzionalità.

Chi è impattato e con quale urgenza

Installazione self-managed via Helm

Se hai installato ingress-nginx manualmente tramite Helm, sei esposto direttamente al ritiro upstream avvenuto a marzo 2026. Da quel momento, qualsiasi vulnerabilità nel controller resta senza patch: mantenerlo in produzione è un rischio di sicurezza crescente nel tempo.

AKS Application Routing add-on

Se usi l’add-on gestito di AKS abilitato con --enable-app-routing, hai tempo fino a novembre 2026. Microsoft garantisce patch per le vulnerabilità critiche fino a quella data. È un margine utile, ma non è una soluzione permanente.

Altro controller Ingress (Traefik, Istio, HAProxy…)

Se non usi NGINX Ingress, questo annuncio non ti impatta direttamente. Vale però la pena iniziare a familiarizzare con Gateway API, che è la direzione dell’intero ecosistema Kubernetes.

Gateway API: il nuovo modello di risorse

La migrazione da Ingress a Gateway API cambia il modello di risorse con cui si lavora. Ecco un confronto diretto tra i due approcci.

Una configurazione Ingress tipica con annotation NGINX:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: my-api
            port:
              number: 80

La configurazione equivalente con Gateway API:

# Definito dal platform team (una volta sola)
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: gateway-system
spec:
  gatewayClassName: azure-application-lb
  listeners:
  - name: http
    port: 80
    protocol: HTTP
---
# Definito dal team applicativo
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app
spec:
  parentRefs:
  - name: my-gateway
    namespace: gateway-system
  hostnames:
  - app.example.com
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: my-api
      port: 80

Il vantaggio principale non è solo sintattico: la separazione tra Gateway e HTTPRoute permette al platform team di gestire centralmente le policy di sicurezza, TLS e throttling, mentre i team applicativi possono modificare le route senza toccare l’infrastruttura condivisa.

Piano di migrazione consigliato

Microsoft sta investendo nel supporto nativo di Gateway API nell’add-on Application Routing di AKS, con Azure Application Gateway for Containers (AGC) come backend raccomandato. I passi pratici per avviare la migrazione sono:

1. Inventario: esegui kubectl get ingress -A -o yaml per elencare tutte le risorse Ingress e mappare le annotation nginx in uso nel cluster.
2. Assessment delle annotation: identifica quali annotation hanno un equivalente nativo in Gateway API (la maggior parte) e quali richiedono configurazioni alternative (timeout avanzati, snippet custom).
3. Ambiente di test: crea un cluster AKS di test con Gateway API abilitato e migra prima i workload meno critici per acquisire familiarità con il nuovo modello.
4. Migrazione progressiva: usa la funzionalità di traffic splitting di HTTPRoute per spostare gradualmente il traffico dai vecchi Ingress alle nuove route, validando il comportamento prima di dismettere il vecchio controller.
5. Cleanup: rimuovi le risorse Ingress e disabilita o disinstalla ingress-nginx una volta completata la validazione su tutti gli ambienti.

Conclusione

La fine di NGINX Ingress su AKS era prevedibile da quando il progetto upstream ha iniziato a mostrare segni di abbandono. La buona notizia è che Gateway API è tecnicamente superiore: più espressiva, più portabile, con una governance delle responsabilità più chiara tra platform team e team applicativi. Chi pianifica la migrazione adesso, con il margine di tempo concesso da Microsoft fino a novembre 2026, può affrontarla con calma. Chi aspetta l’ultimo momento si troverà a gestire una migrazione d’emergenza in un contesto di sicurezza degradante.

La documentazione ufficiale di Gateway API è disponibile su gateway-api.sigs.k8s.io. La roadmap di AKS per Gateway API è tracciabile nelle release note del servizio Azure.

Fonte: The End of NGINX Ingress on AKS: What You Need to Know – Trailhead Technology

The End of NGINX Ingress on AKS: What You Need to Know - Trailhead Technology Partners

Learn about the retiring of NGINX Ingress support coming to AKS in November 2026, what triggered it, and what your migration path looks like.

^{Piotr Kolodziej (Trailhead Technology Partners)}

The Privacy Post

2026-05-05 05:00:00

LinkedIn blocca i vostri diritti GDPR dietro un paywall

Data Subject Rights

[strong]LinkedIn tiene traccia delle visite alle pagine del profilo. Tuttavia, se si vuole vedere chi ha visitato il proprio profilo, bisogna pagare. La filiale di Microsoft utilizza questi e altri "insight" per incentivare le persone a iscriversi all'abbonamento Premium a pagamento. Non è chiaro se questo monitoraggio dei visitatori sia legale. Ciò che è chiaro, tuttavia, è che se questi dati vengono visualizzati come parte di un abbonamento Premium, dovrebbero anche essere accessibili in risposta a una richiesta di accesso ai sensi dell'articolo 15 del GDPR. Ma LinkedIn si rifiuta di rispettare la norma, adducendo improvvisamente presunti problemi di protezione dei dati che, a quanto pare, si presentano solo in caso di richiesta di accesso.[/strong]

• Denuncia contro LinkedIn (DE)

Vendita di dati: Sì! Diritto di accesso: No? LinkedIn cerca costantemente di invogliare i propri utenti a sottoscrivere un abbonamento premium a pagamento. Questo viene promosso principalmente attraverso una funzione che consente agli utenti di visualizzare un elenco di tutti i visitatori del loro profilo negli ultimi 365 giorni. Anche molti altri provider cercano di utilizzare i dati degli utenti per creare un prodotto premium. Tuttavia, secondo la legge dell'UE, tali dati personali dovrebbero essere accessibili gratuitamente. Ciò pone LinkedIn di fronte a un dilemma legale: i dati nascosti dietro un abbonamento premium dovrebbero essere resi disponibili anche nell'ambito di una richiesta di accesso gratuito ai sensi dell'articolo 15 del GDPR.

LinkedIn tiene traccia delle visite al profilo. Il motivo è che i dati dei visitatori, in una certa misura, costituiscono dati condivisi tra i visitatori e coloro i cui profili vengono visitati. Tali dati sulle attività vengono spesso analizzati per personalizzare i contenuti o le pubblicità visualizzate. Sebbene LinkedIn consenta agli utenti di rinunciare a questo tracciamento, non chiede un consenso attivo (opt-in). È quindi lecito chiedersi fino a che punto la registrazione delle visite al profilo sia legale.

Martin Baumann, avvocato specializzato in protezione dei dati presso noyb: "Vendere i dati ai propri utenti è una pratica molto diffusa tra le aziende. In realtà, però, le persone hanno il diritto di ricevere gratuitamente i propri dati. È assurdo che le aziende sembrino riconoscere l'importanza della protezione dei dati solo quando vogliono venderli. Per esempio, quando LinkedIn non ha problemi a consegnare alcuni dati in cambio di denaro - ma improvvisamente si preoccupa della privacy degli altri utenti quando si esercita il diritto di accesso"

Protezione dei dati contro protezione dei dati. È particolarmente assurdo che LinkedIn utilizzi un presunto "interesse alla protezione dei dati" come argomento per negare il diritto di accesso ai dati ai sensi del GDPR. O i dati non devono essere accessibili a nessuno, oppure - se è chiaro al visitatore che i dati sono visibili - devono essere divulgati in conformità all'articolo 15 del GDPR.

Martin Baumann, avvocato specializzato in protezione dei dati presso noyb: "La protezione dei diritti e delle libertà altrui può sicuramente essere un motivo per non divulgare i dati personali condivisi. Tuttavia, se un'azienda ha richiesto il relativo consenso ed è chiaramente disposta a rendere disponibili gli stessi dati a pagamento, questo argomento non regge più"

I diritti del GDPR come opportunità di guadagno? Il GDPR stabilisce vari diritti per consentire agli utenti di accedere e modificare i propri dati nella società dell'informazione. Tuttavia, le aziende spesso continuano a chiedere un compenso per questo, sia che si tratti di richieste di accesso con un'associazione di creditori o la correzione dei correzione dei nomi sui biglietti. Spesso si tratta di tariffe stabilite da tempo, ma illegali.

Denuncia presentata.noyb ha quindi presentato un reclamo all'Autorità austriaca per la protezione dei dati per conto di un utente di LinkedIn e chiede una risposta completa alla sua richiesta di accesso. Inoltre, noyb propone l'imposizione di una multa per evitare violazioni simili in futuro.

---

noyb.eu/it/linkedin-locks-your…