Buongiorno a tutti,

Sono Erika, sto muovendo i primi passi nel fediverso -con non poche difficoltà-.

Sto cercando di capire dove io intenda collocarmi e ammetto di aver aperto un’infinità di profili su vari server, sicuramente sbagliando l’approccio.

Magari qualcuno può illustrarmi qualche possibilità per muovermi meglio nella rete.

Utilizzavo Instagram per educazione personale su temi come: trasfemminismo, politica nazionale ed internazionale, informazione indipendente, scienza ed altro. Avevo un podcast di lettura ad alta voce di fiabe della tradizione con musiche originali, sto cercando un luogo dove rilocarlo dopo aver lasciato spotify. Cucio robe e tento di farne un lavoro.
Erika

Ecco un po’ di foto dalle nostre Cellule Coscioni in giro per l’Italia: soggetto di questo mese, il ciclo di eventi “Una dose di realtà” su salute mentale e psichedelici, che si sono svolti in Sardegna. Clicca sull’icona della macchina fotografica per scorrere le foto!

L'articolo La Gallery di Agosto proviene da Associazione Luca Coscioni.

When you visit almost any website, you’ll see a pop-up asking you to accept, decline, or customize the cookies it collects. Sometimes, it just tells you that cookies are in use by default. We randomly checked 647 websites, and 563 of them displayed cookie notifications. Most of the time, users don’t even pause to think about what’s really behind the banner asking them to accept or decline cookies.

We owe cookie warnings to the adoption of new laws and regulations, such as GDPR, that govern the collection of user information and protection of personal data. By adjusting your cookie settings, you can minimize the amount of information collected about your online activity. For example, you can decline to collect and store third-party cookies. These often aren’t necessary for a website to function and are mainly used for marketing and analytics. This article explains what cookies are, the different types, how they work, and why websites need to warn you about them. We’ll also dive into sensitive cookies that hold the Session ID, the types of attacks that target them, and ways for both developers and users to protect themselves.

What are browser cookies?

Cookies are text files with bits of data that a web server sends to your browser when you visit a website. The browser saves this data on your device and sends it back to the server with every future request you make to that site. This is how the website identifies you and makes your experience smoother.

Let’s take a closer look at what kind of data can end up in a cookie.

First, there’s information about your actions on the site and session parameters: clicks, pages you’ve visited, how long you were on the site, your language, region, items you’ve added to your shopping cart, profile settings (like a theme), and more. This also includes data about your device: the model, operating system, and browser type.

Your sign-in credentials and security tokens are also collected to identify you and make it easier for you to sign in. Although it’s not recommended to store this kind of information in cookies, it can happen, for example, when you check the “Remember me” box. Security tokens can become vulnerable if they are placed in cookies that are accessible to JS scripts.

Another important type of information stored in cookies that can be dangerous if it falls into the wrong hands is the Session ID: a unique code assigned to you when you visit a website. This is the main target of session hijacking attacks because it allows an attacker to impersonate the user. We’ll talk more about this type of attack later. It’s worth noting that a Session ID can be stored in cookies, or it can even be written directly into the URL of the page if the user has disabled cookies.

Example of a Session ID as displayed in the Firefox browser’s developer panel

Example of a Session ID as seen in a URL address: example.org/?account.php?osCsid=dawnodpasb<...>abdisoa.

Besides the information mentioned above, cookies can also hold some of your primary personal data, such as your phone number, address, or even bank card details. They can also inadvertently store confidential company information that you’ve entered on a website, including client details, project information, and internal documents.

Many of these data types are considered sensitive. This means if they are exposed to the wrong people, they could harm you or your organization. While things like your device type and what pages you visited aren’t typically considered confidential, they still create a detailed profile of you. This information could be used by attackers for phishing scams or even blackmail.

Main types of cookies

Cookies by storage time

Cookies are generally classified based on how long they are stored. They come in two main varieties: temporary and persistent.

Temporary, or session cookies, are used during a visit to a website and deleted as soon as you leave. They save you from having to sign in every time you navigate to a new page on the same site or to re-select your language and region settings. During a single session, these values are stored in a cookie because they ensure uninterrupted access to your account and proper functioning of the site’s features for registered users. Additionally, temporary cookies include things like entries in order forms and pages you visited. This information can end up in persistent cookies if you select options like “Remember my choice” or “Save settings”. It’s important to note that session cookies won’t get deleted if you have your browser set to automatically restore your previous session (load previously opened tabs). In this case, the system considers all your activity on that site as one session.

Persistent cookies, unlike temporary ones, stick around even after you leave the site. The website owner sets an expiration date for them, typically up to a year. You can, however, delete them at any time by clearing your browser’s cookies. These cookies are often used to store sign-in credentials, phone numbers, addresses, or payment details. They’re also used for advertising to determine your preferences. Sensitive persistent cookies often have a special attribute HttpOnly. This prevents your browser from accessing their contents, so the data is sent directly to the server every time you visit the site.

Notably, depending on your actions on the website, credentials may be stored in either temporary or persistent cookies. For example, when you simply navigate a site, your username and password might be stored in session cookies. But if you check the “Remember me” box, those same details will be saved in persistent cookies instead.

Cookies by source

Based on the source, cookies are either first-party or third-party. The former are created and stored by the website, and the latter, by other websites. Let’s take a closer look at these cookie types.

First-party cookies are generally used to make the site function properly and to identify you as a user. However, they can also perform an analytics or marketing function. When this is the case, they are often considered optional – more on this later – unless their purpose is to track your behavior during a specific session.

Third-party cookies are created by websites that the one you’re visiting is talking to. The most common use for these is advertising banners. For example, a company that places a banner ad on the site can use a third-party cookie to track your behavior: how many times you click on the ad and so on. These cookies are also used by analytics services like Google Analytics or Yandex Metrica.

Social media cookies are another type of cookies that fits into this category. These are set by widgets and buttons, such as “Share” or “Like”. They handle any interactions with social media platforms, so they might store your sign-in credentials and user settings to make those interactions faster.

Cookies by importance

Another way to categorize cookies is by dividing them into required and optional.

Required or essential cookies are necessary for the website’s basic functions or to provide the service you’ve specifically asked for. This includes temporary cookies that track your activity during a single visit. It also includes security cookies, such as identification cookies, which the website uses to recognize you and spot any fraudulent activity. Notably, cookies that store your consent to save cookies may also be considered essential if determined by the website owner, since they are necessary to ensure the resource complies with your chosen privacy settings.

The need to use essential cookies is primarily relevant for websites that have a complex structure and a variety of widgets. Think of an e-commerce site that needs a shopping cart and a payment system, or a photo app that has to save images to your device.

A key piece of data stored in required cookies is the above-mentioned Session ID, which helps the site identify you. If you don’t allow this ID to be saved in a cookie, some websites will put it directly in the page’s URL instead. This is a much riskier practice because URLs aren’t encrypted. They’re also visible to analytics services, tracking tools, and even other users on the same network as you, which makes them vulnerable to cross-site scripting (XSS) attacks. This is a major reason why many sites won’t let you disable required cookies for your own security.

Example of required cookies on the Osano CMP website

Optional cookies are the ones that track your online behavior for marketing, analytics, and performance. This category includes third-party cookies created by social media platforms, as well as performance cookies that help the website run faster and balance the load across servers. For instance, these cookies can track broken links to improve a website’s overall speed and reliability.

Essentially, most optional cookies are third-party cookies that aren’t critical for the site to function. However, the category can also include some first-party cookies for things like site analytics or collecting information about your preferences to show you personalized content.

While these cookies generally don’t store your personal information in readable form, the data they collect can still be used by analytics tools to build a detailed profile of you with enough identifying information. For example, by analyzing which sites you visit, companies can make educated guesses about your age, health, location, and much more.

A major concern is that optional cookies can sometimes capture sensitive information from autofill forms, such as your name, home address, or even bank card details. This is exactly why many websites now give you the choice to accept or decline the collection of this data.

Special types of cookies

Let’s also highlight special subtypes of cookies managed with the help of two similar technologies that enable non-standard storage and retrieval methods.

A supercookie is a tracking technology that embeds cookies into website headers and stores them in non-standard locations, such as HTML5 local storage, browser plugin storage, or browser cache. Because they’re not in the usual spot, simply clearing your browser’s history and cookies won’t get rid of them.

Supercookies are used for personalizing ads and collecting analytical data about the user (for example, by internet service providers). From a privacy standpoint, supercookies are a major concern. They’re a persistent and hard-to-control tracking mechanism that can monitor your activity without your consent, which makes it tough to opt out.

Another unusual tracking method is Evercookie, a type of zombie cookie. Evercookies can be recovered with JavaScript even after being deleted. The recovery process relies on the unique user identifier (if available), as well as traces of cookies stored across all possible browser storage locations.

How cookie use is regulated

The collection and management of cookies are governed by different laws around the world. Let’s review the key standards from global practices.

1. General Data Protection Regulation (GDPR) and ePrivacy Directive (Cookie Law) in the European Union.
   Under EU law, essential cookies don’t require user consent. This has created a loophole for some websites. You might click “Reject All”, but that button might only refuse non-essential cookies, allowing others to still be collected.
2. Lei Geral de Proteção de Dados Pessoais (LGPD) in Brazil.
   This law regulates the collection, processing, and storage of user data within Brazil. It is largely inspired by the principles of GDPR and, similarly, requires free, unequivocal, and clear consent from users for the use of their personal data. However, LGPD classifies a broader range of information as personal data, including biometric and genetic data. It is important to note that compliance with GDPR does not automatically mean compliance with LGPD, and vice versa.
3. California Consumer Privacy Act (CCPA) in the United States.
   The CCPA considers cookies a form of personal information. This means their collection and storage must follow certain rules. For example, any California resident has the right to stop cross-site cookie tracking to prevent their personal data from being sold. Service providers are required to give users choices about what data is collected and how it’s used.
4. The UK’s Privacy and Electronic Communications Regulations (PECR, or EC Directive) are similar to the Cookie Law.
   PECR states that websites and apps can only save information on a user’s device in two situations: when it’s absolutely necessary for the site to work or provide a service, or when the user has given their explicit consent to this.
5. Federal Law No. 152-FZ “On Personal Data” in Russia.
   The law broadly defines personal data as any information that directly or indirectly relates to an individual. Since cookies can fall under this definition, they can be regulated by this law. This means websites must get explicit consent from users to process their data.

In Russia, website owners must inform users about the use of technical cookies, but they don’t need to get consent to collect this information. For all other types of cookies, user consent is required. Often, the user gives this consent automatically when they first visit the site, as it’s stated in the default cookie warning.

Some sites use a banner or a pop-up window to ask for consent, and some even let users choose exactly which cookies they’re willing to store on their device.

Beyond these laws, website owners create their own rules for using first-party cookies. Similarly, third-party cookies are managed by the owners of third-party services, such as Google Analytics. These parties decide what kind of information goes into the cookies and how it’s formatted. They also determine the cookies’ lifespan and security settings. To understand why these settings are so important, let’s look at a few ways malicious actors can attack one of the most critical types of cookies: those that contain a Session ID.

Session hijacking methods

As discussed above, cookies containing a Session ID are extremely sensitive. They are a prime target for cybercriminals. In real-world attacks, different methods for stealing a Session ID have been documented. This is a practice known as session hijacking. Below, we’ll look at a few types of session hijacking.

Session sniffing

One method for stealing cookies with a Session ID is session sniffing, which involves intercepting traffic between the user and the website. This threat is a concern for websites that use the open HTTP protocol instead of HTTPS, which encrypts traffic. With HTTP, cookies are transmitted in plain text within the headers of HTTP requests, which makes them vulnerable to interception.

Attacks targeting unencrypted HTTP traffic mostly happen on public Wi-Fi networks, especially those without a password and strong security protocols like WPA2 or WPA3. These protocols use AES encryption to protect traffic on Wi-Fi networks, with WPA3 currently being the most secure version. While WPA2/WPA3 protection limits the ability to intercept HTTP traffic, only implementing HTTPS can truly protect against session sniffing.

This method of stealing Session ID cookies is fairly rare today, as most websites now use HTTPS encryption. The popularity of this type of attack, however, was a major reason for the mass shift to using HTTPS for all connections during a user’s session, known as HTTPS everywhere.

Cross-site scripting (XSS)

Cross-site scripting (XSS) exploits vulnerabilities in a website’s code to inject a malicious script, often written in JavaScript, onto its webpages. This script then runs whenever a victim visits the site. Here’s how an XSS attack works: an attacker finds a vulnerability in the source code of the target website that allows them to inject a malicious script. For example, the script might be hidden in a URL parameter or a comment on the page. When the user opens the infected page, the script executes in their browser and gains access to the site’s data, including the cookies that contain the Session ID.

Session fixation

In a session fixation attack, the attacker tricks your browser into using a pre-determined Session ID. Thus, the attacker prepares the ground for intercepting session data after the victim visits the website and performs authentication.

Here’s how it goes down. The attacker visits a website and gets a valid, but unauthenticated, Session ID from the server. They then trick you into using that specific Session ID. A common way to do this is by sending you a link with the Session ID already embedded in the URL, like this: http://example.com/?SESSIONID=ATTACKER_ID. When you click the link and sign in, the website links the attacker’s Session ID to your authenticated session. The attacker can then use the hijacked Session ID to take over your account.

Modern, well-configured websites are much less vulnerable to session fixation than XSS-like attacks because most current web frameworks automatically change the user’s Session ID after they sign in. However, the very existence of this Session ID exploitation attack highlights how crucial it is for websites to securely manage the entire lifecycle of the user session, especially at the moment of sign-in.

Cross-site request forgery (CSRF)

Unlike session fixation or sniffing attacks, cross-site request forgery (CSRF or XSRF) leverages the website’s trust in your browser. The attacker forces your browser, without your knowledge, to perform an unwanted action on a website where you’re signed in – like changing your password or deleting data.

For this type of attack, the attacker creates a malicious webpage or an email message with a harmful link, piece of HTML code, or script. This code contains a request to a vulnerable website. You open the page or email message, and your browser automatically sends the hidden request to the target site. The request includes the malicious action and all the necessary (for example, temporary) cookies for that site. Because the website sees the valid cookies, it treats the request as a legitimate one and executes it.

Variants of the man-in-the-middle (MitM) attack

A man-in-the-middle (MitM) attack is when a cybercriminal not only snoops on but also redirects all the victim’s traffic through their own systems, thus gaining the ability to both read and alter the data being transmitted. Examples of these attacks include DNS spoofing or the creation of fake Wi-Fi hotspots that look legitimate. In an MitM attack, the attacker becomes the middleman between you and the website, which gives them the ability to intercept data, such as cookies containing the Session ID.

Websites using the older HTTP protocol are especially vulnerable to MitM attacks. However, sites using the more secure HTTPS protocol are not entirely safe either. Malicious actors can try to trick your browser with a fake SSL/TLS certificate. Your browser is designed to warn you about suspicious invalid certificates, but if you ignore that warning, the attacker can decrypt your traffic. Cybercriminals can also use a technique called SSL stripping to force your connection to switch from HTTPS to HTTP.

Predictable Session IDs

Cybercriminals don’t always have to steal your Session ID – sometimes they can just guess it. They can figure out your Session ID if it’s created according to a predictable pattern with weak, non-cryptographic characters. For example, a Session ID may contain your IP address or consecutive numbers, and a weak algorithm that uses easily predictable random sequences may be used to generate it.

To carry out this type of attack, the malicious actor will collect a sufficient number of Session ID examples. They analyze the pattern to figure out the algorithm used to create the IDs, then apply that knowledge to predicting your current or next Session ID.

Cookie tossing

This attack method exploits the browser’s handling of cookies set by subdomains of a single domain. If a malicious actor takes control of a subdomain, they can try to manipulate higher-level cookies, in particular the Session ID. For example, if a cookie is set for sub.domain.com with the Domain attribute set to .domain.com, that cookie will also be valid for the entire domain.

This lets the attacker “toss” their own malicious cookies with the same names as the main domain’s cookies, such as Session_id. When your browser sends a request to the main server, it includes all the relevant cookies it has. The server might mistakenly process the hacker’s Session ID, giving them access to your user session. This can work even if you never visited the compromised subdomain yourself. In some cases, sending invalid cookies can also cause errors on the server.

How to protect yourself and your users

The primary responsibility for cookie security rests with website developers. Modern ready-made web frameworks generally provide built-in defenses, but every developer should understand the specifics of cookie configuration and the risks of a careless approach. To counter the threats we’ve discussed, here are some key recommendations.

Recommendations for web developers

All traffic between the client and server must be encrypted at the network connection and data exchange level. We strongly recommend using HTTPS and enforcing automatic redirect from HTTP to HTTPS. For an extra layer of protection, developers should use the HTTP Strict Transport Security (HSTS) header, which forces the browser to always use HTTPS. This makes it much harder, and sometimes impossible, for attackers to slip into your traffic to perform session sniffing, MitM, or cookie tossing attacks.

It must be mentioned that the use of HTTPS is insufficient protection against XSS attacks. HTTPS encrypts data during transmission, while an XSS script executes directly in the user’s browser within the HTTPS session. So, it’s up to the website owner to implement protection against XSS attacks. To stop malicious scripts from getting in, developers need to follow secure coding practices:

• Validate and sanitize user input data.
• Implement mandatory data encoding (escaping) when rendering content on the page – this way, the browser will not interpret malicious code as part of the page and will not execute it.
• Use the HttpOnly flag to protect cookie files from being accessed by the browser.
• Use the Content Security Policy (CSP) standard to control code sources. It allows monitoring which scripts and other content sources are permitted to execute and load on the website.

For attacks like session fixation, a key defense is to force the server to generate a new Session ID right after the user successfully signs in. The website developer must invalidate the old, potentially compromised Session ID and create a new one that the attacker doesn’t know.

An extra layer of protection involves checking cookie attributes. To ensure protection, it is necessary to check for the presence of specific flags (and set them if they are missing): Secure and HttpOnly. The Secure flag ensures that cookies are transmitted over an HTTPS connection, while HttpOnly prevents access to them from the browser, for example through scripts, helping protect sensitive data from malicious code. Having these attributes can help protect against session sniffing, MitM, cookie tossing, and XSS.

Pay attention to another security attribute, SameSite, which can restrict cookie transmission. Set it to Lax or Strict for all cookies to ensure they are sent only to trusted web addresses during cross-site requests and to protect against CSRF attacks. Another common strategy against CSRF attacks is to use a unique, randomly generated CSRF token for each user session. This token is sent to the user’s browser and must be included in every HTTP request that performs an action on your site. The site then checks to make sure the token is present and correct. If it’s missing or doesn’t match the expected value, the request is rejected as a potential threat. This is important because if the Session ID is compromised, the attacker may attempt to replace the CSRF token.

To protect against an attack where a cybercriminal tries to guess the user’s Session ID, you need to make sure these IDs are truly random and impossible to predict. We recommend using a cryptographically secure random number generator that utilizes powerful algorithms to create hard-to-predict IDs. Additional protection for the Session ID can be ensured by forcing its regeneration after the user authenticates on the web resource.

The most effective way to prevent a cookie tossing attack is to use cookies with the __Host- prefix. These cookies can only be set on the same domain that the request originates from and cannot have a Domain attribute specified. This guarantees that a cookie set by the main domain can’t be overwritten by a subdomain.

Finally, it’s crucial to perform regular security checks on all your subdomains. This includes monitoring for inactive or outdated DNS records that could be hijacked by an attacker. We also recommend ensuring that any user-generated content is securely isolated on its own subdomain. User-generated data must be stored and managed in a way that prevents it from compromising the security of the main domain.

As mentioned above, if cookies are disabled, the Session ID can sometimes get exposed in the website URL. To prevent this, website developers must embed this ID into essential cookies that cannot be declined.

Many modern web development frameworks have built-in security features that can stop most of the attack types described above. These features make managing cookies much safer and easier for developers. Some of the best practices include regular rotation of the Session ID after the user signs in, use of the Secure and HttpOnly flags, limiting the session lifetime, binding it to the client’s IP address, User-Agent string, and other parameters, as well as generating unique CSRF tokens.

There are other ways to store user data that are both more secure and better for performance than cookies.

Depending on the website’s needs, developers can use different tools, like the Web Storage API (which includes localStorage and sessionStorage), IndexedDB, and other options. When using an API, data isn’t sent to the server with every single request, which saves resources and makes the website perform better.

Another exciting alternative is the server-side approach. With this method, only the Session ID is stored on the client side, while all the other data stays on the server. This is even more secure than storing data with the help of APIs because private information is never exposed on the client side.

Tips for users

Staying vigilant and attentive is a big part of protecting yourself from cookie hijacking and other malicious manipulations.

Always make sure the website you are visiting is using HTTPS. You can check this by looking at the beginning of the website address in the browser address bar. Some browsers let the user view additional website security details. For example, in Google Chrome, you can click the icon right before the address.

This will show you if the “Connection is secure” and the “Certificate is valid”. If these details are missing or data is being sent over HTTP, we recommend maximum caution when visiting the website and, whenever possible, avoiding entering any personal information, as the site does not meet basic security standards.

When browsing the web, always pay attention to any security warnings your browser gives you, especially about suspicious or invalid certificates. Seeing one of these warnings might be a sign of an MitM attack. If you see a security warning, it’s best to stop what you’re doing and leave that website right away. Many browsers implement certificate verification and other security features, so it is important to install browser updates promptly – this replaces outdated and compromised certificates.

We also recommend regularly clearing your browser data (cookies and cache). This can help get rid of outdated or potentially compromised Session IDs.

Always use two-factor authentication wherever it’s available. This makes it much harder for a malicious actor to access your account, even if your Session ID is exposed.

When a site asks for your consent to use cookies, the safest option is to refuse all non-essential ones, but we’ll reiterate that sometimes, clicking “Reject cookies” only means declining the optional ones. If this option is unavailable, we recommend reviewing the settings to only accept the strictly necessary cookies. Some websites offer this directly in the pop-up cookie consent notification, while others provide it in advanced settings.

The universal recommendation to avoid clicking suspicious links is especially relevant in the context of preventing Session ID theft. As mentioned above, suspicious links can be used in what’s known as session fixation attacks. Carefully check the URL: if it contains parameters you do not understand, we recommend copying the link into the address bar manually and removing the parameters before loading the page. Long strings of characters in the parameters of a legitimate URL may turn out to be an attacker’s Session ID. Deleting it renders the link safe. While you’re at it, always check the domain name to make sure you’re not falling for a phishing scam.

In addition, we advise extreme caution when connecting to public Wi-Fi networks. Man-in-the-middle attacks often happen through open networks or rogue Wi-Fi hotspots. If you need to use a public network, never do it without a virtual private network (VPN), which encrypts your data and makes it nearly impossible for anyone to snoop on your activity.

securelist.com/cookies-and-ses…

Over the years Intel has introduced a number of new computer form factors that either became a hit, fizzled out, or moved on to live a more quiet life. The New Unit of Computing (NUC) decidedly became a hit with so-called Mini PCs now everywhere, while the Intel Compute Stick has been largely forgotten. In a recent video by the [Action Retro] one such Compute Stick is poked at, specifically the last model released by Intel in the form of the 2016-era STK1AW32SC, featuring a quad-core Intel Atom x5-Z8330 SoC, 2 GB of RAM and 32 GB eMMC storage.

As the name suggests, this form factor is very stick-like, with a design that makes it easy to just plug it into the HDMI port of a display, making it a snap to add a computer to any TV or such without taking up a considerable amount of space. Although Intel didn’t make more of them after this model, it could be argued that devices like the Chromecast dongle follow the same general concept, and manufacturers like MeLe are still making new PCs in this form factor today.

In the video this 2016-era Compute Stick is put through its paces, wiping the Windows 10 installation that was still on it from the last time it was used, and an installation of Haiku was attempted which unfortunately failed to see the eMMC storage. Worse was the current Ubuntu, which saw its installer simply freeze up, but MX Linux saved the day, providing a very usable Linux desktop experience including the watching of YouTube content and network streaming of Steam games.

Although dissed as ‘e-waste’ by many today, if anything this video shows that these little sticks are still very capable computers in 2025.

youtube.com/embed/G3WvOzdlpwY?…

hackaday.com/2025/09/02/rememb…

While you can still find tape being used for backup storage, it’s pretty safe to say that the humble audio cassette is about as out of date as a media format can be. Still, it has a certain retro charm we’re suckers for, particularly in the shape of a Commodore Datasette. We’re also suckers for miniaturization, so how could we not fall for [bitluni] ‘s tiny datasette replica?

Aesthetically, he’s copying the Commodore original to get those sweet nostalgia juices flowing, but to make things more interesting he’s not using compact cassette tapes. Instead, [bitluni] started with a mini cassette dictaphone, which he tore down to its essentials and rebuilt into the Commodore-shaped case.

The prototyping of this project was full of hacks — like building a resistor ladder DAC in an unpopulated part of a spare PCB from an unrelated project. The DAC is of course key to getting data onto the mini-casettes. After some playing around [bitluni] decided that encoding data with FSK (frequency-shift keying), as was done back on the C-64, was the way to go. (Almost like those old engineers knew what they were doing!) The dictaphone tape transport is inferior to the old Datasette, though, so as a cheap error-correction hack, [bitluni] needed to duplicate each byte to make sure it gets read correctly.

The mini cassettes only fit a laughable amount of data by modern standards this way (about 1 MB) but, of course that’s not the point. If you jump to 11:33 in the video embedded below, you can see the point: the shout of triumph when loading PacMan (all 8 kB of it) from tape via USB. That transfer was via serial console; eventually [bitluni] intends to turn this into the world’s least-practical mass storage device, but that wasn’t necessary for proof-of-concept. The code for what’s shown is available on GitHub.

If you have an old Datasette you want to use with a modern PC, you’d better believe that we’ve got you covered. We’ve seen other cassette-mass-storage interfaces over the years, too. It might be a dead medium, but there’s just something about “sticky tape and rust” that lives on in our imaginations.

youtube.com/embed/GQwTPH67YqY?…

Thanks to [Stephen Walters] for the tip.

hackaday.com/2025/09/01/tiny-d…

La recente conferma da parte di Zscaler riguardo a una violazione dati derivante da un attacco alla supply chain fornisce un caso studio sull’evoluzione delle minacce contro ecosistemi SaaS complessi. L’attacco, attribuito al gruppo APT UNC6395, ha sfruttato vulnerabilità a livello di gestione delle credenziali OAuth e di API trust model nelle integrazioni tra applicazioni di terze parti e piattaforme cloud.

Secondo le prime analisi, il punto d’ingresso è stato l’abuso dell’integrazione tra Salesloft Drift e Salesforce. L’attore ha esfiltrato token OAuth validi, consentendo l’accesso diretto agli endpoint Salesforce senza dover interagire con i sistemi di autenticazione tradizionali (es. MFA o session cookies).

Questo vettore sfrutta un punto debole intrinseco nel protocollo OAuth: i bearer token. Un bearer token, se sottratto, garantisce pieno accesso fino alla sua scadenza, indipendentemente dal contesto in cui viene utilizzato. una volta ottenuto il bearer token OAuth (es. tramite furto da log, memory dump, o intercettazione),

lo si può riutilizzare in un’altra sessione, da un altro dispositivo o da un’altra rete, senza dover conoscere la password o superare l’autenticazione a più fattori. In pratica, il token rubato diventa un “passaporto valido” fino alla sua scadenza.

Gli aggressori hanno quindi orchestrato enumerazioni automatizzate via script Python, con query massicce alle API Salesforce, ottenendo dataset contenenti email, numeri di telefono e altre informazioni di contatto business.

Analisi TTP

• Initial Access: sfruttamento dell’integrazione SaaS (Salesloft Drift → Salesforce).
• Credential Access: esfiltrazione di OAuth tokens mediante attacchi mirati a log o ambienti CI/CD compromessi.
• Defense Evasion: utilizzo di token validi per evitare alert su login anomali o tentativi MFA falliti.
• Collection: scraping massivo tramite script Python (indicatore di automazione e infrastruttura consolidata).
• Exfiltration: trasferimento dei dataset su infrastrutture C2, probabilmente distribuite su cloud provider legittimi per confondere il traffico.

Questo approccio dimostra un livello elevato di maturità operativa, con chiara attenzione alla persistenza stealth e al mascheramento nel rumore operativo SaaS.

Zscaler ha confermato che la compromissione è circoscritta all’ambiente Salesforce e non ai sistemi core di sicurezza; i dati esfiltrati riguardano informazioni di contatto business, senza impatto diretto sulle infrastrutture di rete o sui servizi SASE; non sono state rilevate manipolazioni di configurazioni o codice eseguibile.

Tuttavia, anche dati apparentemente “a basso impatto” possono costituire una base privilegiata per future operazioni di spear-phishing contro clienti e partner, sfruttando la fiducia nel brand Zscaler.

Considerazioni Architetturali: Debolezze del Modello SaaS

Questo incidente conferma criticità note ma spesso trascurate:

• Token OAuth come single point of failure: senza meccanismi di rotazione rapida, scoping rigoroso e binding contestuale, diventano equivalenti a credenziali statiche.
• API Exposure: le piattaforme SaaS esposte via API spesso mancano di un sistema granulare di rate-limiting e anomaly detection, facilitando scraping su larga scala.
• Third-Party Trust: ogni applicazione integrata amplia il perimetro di rischio; la security posture dell’intero ecosistema dipende dall’anello più debole.
• Visibility Gaps: i log OAuth e le audit trail delle API non sempre sono correttamente centralizzati in SIEM, riducendo la capacità di detection.

Mitigazioni Tecniche e Best Practice

• Token hardening: implementazione di PKCE (Proof Key for Code Exchange) e token binding per ridurre il rischio di replay.
• Rotazione aggressiva: token a breve durata, con refresh gestito tramite canali sicuri.
• Scope minimization: limitare i privilegi dei token al minimo necessario (principio del least privilege).
• API monitoring: anomalie nelle chiamate API (es. spike di richieste, query massive) devono triggerare alert in tempo reale.
• Zero Trust enforcement: anche per le applicazioni interne e SaaS, ogni accesso deve essere verificato dinamicamente in base al contesto.

Conclusioni

L’attacco subito da Zscaler non rappresenta solo un incidente isolato, ma un campanello d’allarme per tutto il settore. Le architetture SaaS, per loro natura interconnesse, erodono il concetto tradizionale di perimetro. In questo scenario, la resilienza dipende dalla capacità di gestire in maniera proattiva tokenization, API exposure e terze parti.

Il caso Zscaler dimostra che anche player globali della sicurezza non sono immuni da vulnerabilità di supply chain. Il futuro della sicurezza cloud richiede un cambio di paradigma: trattare ogni integrazione come un potenziale threat vector e applicare controlli di sicurezza by design a ogni layer della catena di fornitura digitale.

L'articolo Zscaler Violazione Dati: Lezione Apprese sull’Evoluzione delle Minacce SaaS proviene da il blog della sicurezza informatica.

Un attacco informatico di vasta portata ha preso di mira l’azienda di sicurezza Zscaler, la quale ha ufficialmente confermato di essere stata vittima di una violazione nella catena di approvvigionamento. Questo attacco ha portato all’esposizione dei dati di contatto dei clienti a causa di credenziali Salesforce compromesse, collegate alla piattaforma di marketing Salesloft Drift. L’evento, reso pubblico il 31 agosto 2025, rappresenta il risultato di una campagna più vasta che ha avuto come obiettivo i token OAuth di Salesloft Drift, coinvolgendo oltre 700 organizzazioni a livello globale.

La violazione è dovuta a un attacco più ampio alla supply chain su Salesloft Drift, in cui gli autori della minaccia hanno rubato token OAuth e di aggiornamento. Questi token hanno concesso l’accesso non autorizzato alle istanze dei clienti Salesforce, consentendo l’esfiltrazione di informazioni sensibili. Nel suo avviso, Zscaler ha confermato che la sua istanza Salesforce era tra quelle interessate.

“Nell’ambito di questa campagna, soggetti non autorizzati hanno ottenuto l’accesso alle credenziali Salesloft Drift dei suoi clienti, tra cui Zscaler”, ha dichiarato l’azienda. “A seguito di un’analisi dettagliata, abbiamo stabilito che queste credenziali consentivano un accesso limitato ad alcuni dati Salesforce”.

Le informazioni esposte sono le seguenti:

• nomi dei clienti
• Indirizzi email aziendali
• Titoli di lavoro
• Numeri di telefono
• Dettagli regionali/località
• Licenza del prodotto e dettagli commerciali
• Contenuto da alcuni casi di assistenza clienti

La società Zscaler ha fatto sapere che la violazione dei dati ha riguardato esclusivamente il suo sistema Salesforce, escludendo quindi qualsiasi impatto su prodotti, infrastrutture o servizi offerti dalla stessa Zscaler. Nonostante ad oggi non siano emersi casi di abuso, la compagnia ha raccomandato ai propri clienti di rimanere vigili nei confronti di possibili tentativi di phishing o di ingegneria sociale che potrebbero sfruttare le informazioni trapelate.

Zscaler ha messo in atto una serie di misure di mitigazione per contenere l’incidente: sono state revocate tutte le integrazioni di Salesloft Drift con Salesforce, i token API sono stati ruotati per prevenire abusi futuri e, per ridurre i rischi legati all’ingegneria sociale, è stata introdotta un’autenticazione avanzata dei clienti durante le chiamate di supporto. L’azienda ha inoltre confermato che le indagini sull’accaduto restano in corso per identificare con precisione l’entità della compromissione e garantire la piena sicurezza delle integrazioni.

Google Threat Intelligence ha attribuito la compromissione di Drift al gruppo UNC6395, responsabile del furto di casi di supporto Salesforce con l’obiettivo di raccogliere credenziali, chiavi di accesso AWS, token Snowflake e altri dati sensibili. Secondo i ricercatori, gli attaccanti hanno dimostrato avanzate tattiche di sicurezza operativa, come la cancellazione dei processi di query per nascondere le proprie attività, anche se i log sono rimasti disponibili per le analisi forensi. La campagna, tuttavia, non si è limitata all’integrazione Drift–Salesforce: gli hacker hanno compromesso anche Drift Email, ottenendo l’accesso a dati di CRM e marketing automation, oltre a sfruttare token OAuth rubati per infiltrarsi negli account Google Workspace e leggere le email aziendali.

L'articolo Zscaler subisce violazione dati: attacco supply chain tramite Salesloft Drift proviene da il blog della sicurezza informatica.

Benvenuti al primo appuntamento con la nostra rubrica, un percorso di tre settimane per esplorare la straordinaria danza tra coevoluzione, cybersecurity e le discipline umanistiche, con un focus sul coaching. Ogni settimana, affronteremo un aspetto diverso di questo tema, partendo oggi dal cuore del problema: la mente umana.

La coevoluzione è un concetto affascinante, un ballo cosmico in cui due specie, o sistemi, si influenzano reciprocamente, adattandosi e crescendo insieme. Darwin la osservava nei fringuelli delle Galápagos, il cui becco mutava in base ai semi disponibili.

Oggi, possiamo vederla nel mondo digitale, dove la cybersecurity e la psicologia non sono più discipline separate, ma due facce della stessa medaglia in una danza incessante. La mente umana, con le sue vulnerabilità e le sue forze, è il vero campo di battaglia. La sicurezza non è solo una questione di codici e algoritmi, ma una complessa interazione tra tecnologia e comportamento.

L’hacker, come un parassita evoluto, non si limita a forzare serrature digitali. Studia le abitudini, le paure e i desideri delle sue vittime. Crea trappole di ingegneria sociale, come il phishing, che sono il perfetto esempio di coevoluzione parassitaria. Il malware si evolve, ma anche la nostra consapevolezza.

Un esempio lampante è il cosiddetto “Cavallo di Troia” moderno, una metafora che affonda le radici nella mitologia greca. I Greci non vinsero assediando le mura di Troia, ma ingannando il nemico con un dono apparentemente innocuo, che nascondeva un pericolo mortale. Lo stesso accade oggi con le email di phishing. Un’offerta irresistibile, un messaggio urgente da una banca, un allegato che promette un’anteprima succulenta: sono tutti cavalli di Troia progettati per bypassare le nostre difese razionali, agendo direttamente sulle nostre vulnerabilità psicologiche.

La coevoluzione tra hacker e difensore diventa una partita a scacchi. Il difensore non può limitarsi a rafforzare il firewall, ma deve anche educare gli utenti a riconoscere il pericolo. Il cyber-attacco non è più un atto puramente tecnico, ma un atto psicologico. L’hacker sfrutta i nostri bias cognitivi, come il bias di conferma (crediamo a ciò che conferma le nostre convinzioni) o l’euristica dell’affettività (siamo più propensi a fidarci di ciò che ci evoca emozioni positive).

Il difensore, per contrastarlo, deve coevolvere, diventando un “psicologo della sicurezza”.

La Psicologia al servizio della Cybersecurity

Per comprendere questo fenomeno, dobbiamo attingere alla psicologia. Daniel Kahneman, premio Nobel per l’economia e padre della psicologia comportamentale, nel suo libro Pensieri lenti e veloci, spiega come il nostro cervello operi attraverso due sistemi: il Sistema 1, rapido e intuitivo, e il Sistema 2, lento e razionale.

Gli attacchi di ingegneria sociale sono progettati per bypassare il Sistema 2 e attivare il Sistema 1, spingendoci a cliccare su link pericolosi in un momento di fretta o distrazione. L’hacker non attacca la nostra tecnologia, ma il nostro cervello. Un altro concetto fondamentale è quello di “schemi mentali” sviluppato dal psicologo cognitivo Jean Piaget.

Gli schemi sono le strutture che usiamo per interpretare il mondo. Quando un’email di phishing simula perfettamente il logo della nostra banca, attiva lo schema mentale di “comunicazione bancaria fidata”, inducendoci a ignorare i segnali d’allarme.

La coevoluzione, in questo senso, è una battaglia per la costruzione e la decostruzione di questi schemi.

Il Coaching come Antidoto e Guida

Come possiamo, quindi, difenderci? Oltre alla tecnologia, la risposta risiede nello sviluppo di un mindset resiliente. È qui che il coaching entra in gioco, non come un’arma, ma come una guida. Non si tratta di imparare a forzare serrature digitali, ma di imparare a rafforzare la propria mente.

Il coach aiuta l’individuo a diventare consapevole dei propri punti deboli psicologici, a riconoscere gli schemi di pensiero che lo rendono vulnerabile e a sviluppare nuove abitudini digitali. Possiamo vedere il coach come il “mentore” che non ci fornisce la spada per combattere il drago, ma ci insegna a riconoscere le sue trappole e a gestire la nostra paura.

Il coaching promuove una mentalità di apprendimento continuo, cruciale in un ambiente digitale che muta senza sosta.

Invece di sentirsi vittime passive, il coaching ci rende protagonisti attivi della nostra sicurezza, pronti a migliorare dopo ogni attacco, reale o simulato.

Conclusione

In questo primo passo, abbiamo visto come la cybersecurity non sia solo una questione di codici e firewall, ma una profonda battaglia psicologica. La coevoluzione tra hacker e difensore è una danza in cui la comprensione della mente umana è l’arma più potente. Il cyber-attacco non è un atto meccanico, ma un atto psicologico.

Nelle prossime settimane, esploreremo come il coaching possa aiutarci a costruire la nostra resilienza mentale e come la filosofia ci possa dare una bussola morale per navigare le sfide etiche che la coevoluzione digitale ci pone. Vi aspetto per continuare questo affascinante viaggio insieme.

L'articolo Il nuovo campo di battaglia della cybersecurity? Il tuo Cervello! proviene da il blog della sicurezza informatica.

Proofpoint pubblica il report “Voice of the CISO 2025”: cresce il rischio legato all’AI e rimane il problema umano, mentre i CISO sono a rischio burnout. L’84% dei CISO italiani prevede un attacco informatico materiale nel prossimo anno. Rischio umano e perdita di dati dovuta alla GenAI sono in cima alle loro preoccupazioni.

Proofpoint, Inc., azienda leader nella cybersecurity e nella compliance, ha pubblicato oggi la quinta edizione annuale del suo report “Voice of the CISO”, che analizza le principali sfide, aspettative e priorità dei Chief Information Security Officer (CISO) a livello globale. Il report 2025, che ha coinvolto 1.600 CISO a livello mondiale in 16 paesi, evidenzia due tendenze critiche: l’aumento degli attacchi informatici sta alimentando una maggiore ansia tra i CISO – insieme a una crescente disponibilità a pagare riscatti in caso di incidenti – e la rapida ascesa della GenAI sta costringendo i responsabili della sicurezza a bilanciare innovazione e rischio, nonostante le crescenti preoccupazioni relative a esposizione e uso improprio dei dati.

Man mano che le minacce diventano più frequenti e variegate aumenta la preoccupazione sulla capacità della loro organizzazione di resistere a un attacco materiale. L’84% dei CISO italiani si sente a rischio di subire un cyber attacco materiale nei prossimi 12 mesi, eppure il 56% afferma di non essere preparato a rispondere. Oltre tre quarti (77%) dei CISO italiani hanno subìto una perdita di dati materiale nell’ultimo anno, con gli incidenti causati da insider in cima alla lista delle cause. Con il 94% che attribuisce almeno una parte della perdita di dati ai dipendenti in uscita, secondo i risultati dell’indagine, il comportamento umano rimane una vulnerabilità critica. Riflettendo la pressione, il 70% dei CISO italiani afferma anche che prenderebbe in considerazione il pagamento di un riscatto per prevenire fughe di dati o ripristinare i sistemi.

L’AI è rapidamente emersa sia come priorità assoluta che come principale preoccupazione per i CISO: il 69% di quelli italiani ritiene che abilitare l’utilizzo sicuro degli strumenti di GenAI sia una priorità strategica per i prossimi due anni, anche se i timori per la sicurezza persistono. In Italia, il 60% dei CISO esprime preoccupazione per la potenziale perdita di dati dei clienti tramite piattaforme di GenAI pubbliche. Con l’accelerazione dell’adozione, le organizzazioni stanno passando dalla restrizione alla governance, con il 55% che implementa linee guida sull’uso e il 64% che esplora difese basate su AI, sebbene l’entusiasmo sia diminuito rispetto al picco dell’80% dell’anno scorso. Non va sottovalutato l’aspetto personale: i CISO italiani continuano ad affrontare una crescente pressione di fronte a minacce in aumento e risorse limitate: il 61% dichiara di far fronte ad aspettative eccessive e il 55% di aver sperimentato o assistito a burnout nell’ultimo anno.

“I risultati di quest’anno rivelano una crescente disconnessione tra fiducia e capacità tra i CISO,” spiega Patrick Joyce, global resident CISO di Proofpoint. “Mentre molti responsabili della sicurezza esprimono ottimismo sulla postura informatica della loro organizzazione, la realtà racconta una storia diversa: la crescente perdita di dati, le lacune nella preparazione e il persistente rischio umano continuano a minare la resilienza. Con l’accelerazione dell’adozione della GenAI che porta sia opportunità che minacce, ai CISO viene chiesto di fare di più con meno, di navigare in una complessità senza precedenti e di salvaguardare comunque ciò che conta di più. È chiaro che il ruolo del CISO non è mai stato così cruciale, o così sotto pressione.”

Questi i principali risultati italiani emersi dal report “Voice of the CISO 2025”.

• Fiducia contro realtà: i CISO si preparano agli attacchi tra crescente perdita di dati e lacune nella preparazione.L’84% dei CISO italiani si sente a rischio di subire un attacco informatico significativo nei prossimi 12 mesi, percentuale in aumento rispetto al 61% dell’anno scorso. Eppure, il 56% ammette che la propria organizzazione non sia preparata a rispondervi. Oltre tre quarti (77%) hanno subìto una perdita di dati significativa nell’ultimo anno (rispetto al 27% nel 2024) nonostante la maggior parte dei CISO esprima fiducia nella propria cultura della cybersecurity.
• Attacchi su più canali, stesso risultato.I CISO italiani affrontano un panorama di minacce sempre più frammentato: frodi via email (45%), minacce interne (41%), ransomware (31%) e malware (31%) sono le principali preoccupazioni. Nonostante le diverse tattiche utilizzate, la maggior parte degli attacchi porta allo stesso risultato: la perdita di dati. Riflettendo l’elevata posta in gioco, il 70% dei CISO italiani afferma che prenderebbe in considerazione il pagamento di un riscatto per ripristinare i sistemi o prevenire fughe di dati, percentuale che sale all’84% in Canada e Messico.
• I dati non si perdono da soli.Il 94% dei CISO italiani che ha subìto una perdita di informazioni afferma che i dipendenti in uscita hanno avuto una responsabilità, segnalando un deciso aumento rispetto al 52% dell’anno scorso. Nonostante l’adozione quasi universale di strumenti di prevenzione della perdita di dati (DLP), oltre due terzi (36%) affermano che i loro dati rimangono inadeguatamente protetti. Con l’accelerazione della GenAI, il 69% ora classifica protezione e governance delle informazioni come una priorità assoluta, spingendo verso una sicurezza dinamica e consapevole del contesto.
• Il problema delle persone persiste.L’errore umano rimane la principale vulnerabilità della cybersecurity nel 2025, con il 68% dei CISO italiani che cita le persone come il loro rischio maggiore, nonostante il 64% creda che i dipendenti comprendano le migliori pratiche di cybersecurity. Questa incongruenza evidenzia una lacuna critica: la sola consapevolezza non è sufficiente. Oltre un quarto (27%) delle organizzazioni manca ancora di risorse dedicate alla gestione del rischio interno per colmare il divario tra conoscenza e comportamento.
• Amico o nemico? L’AI è un’arma a doppio taglio.La rapida diffusione della GenAI sta amplificando le preoccupazioni relative al rischio umano. Il 60% dei CISO italiani è in apprensione per la perdita di dati dei clienti tramite strumenti di GenAI pubblici, con piattaforme di collaborazione e chatbot di GenAI visti come le principali minacce alla sicurezza. Nonostante ciò, il 69% afferma che abilitare un utilizzo sicuro della GenAI sia una priorità assoluta, evidenziando un passaggio dalla restrizione alla governance. La maggior parte sta rispondendo con delle difese: il 55% ha implementato linee guida per l’uso e il 64% sta esplorando difese basate su AI, sebbene l’entusiasmo si sia raffreddato rispetto all’80% dell’anno scorso. Tre su cinque (61%) limitano del tutto gli strumenti di GenAI da parte dei dipendenti.
• Vacilla l’allineamento con il Consiglio di Amministrazione mentre aumenta la pressione sui CISO.L’allineamento tra Consiglio di Amministrazione e CISO si è ridotto dal 75% del 2024 al 64% di quest’anno. Significativi tempi di inattività aziendale sono diventati la principale preoccupazione dei consigli di amministrazione a seguito di un attacco, segnalando come il rischio cyber stia guadagnando terreno come priorità strategica.
• Anno diverso, stesse pressioni.I CISO italiani continuano ad affrontare una crescente pressione di fronte a minacce in aumento e risorse limitate: il 61% dichiara di affrontare aspettative eccessive e il 55% di aver sperimentato o assistito a burnout nell’ultimo anno. Mentre il 62% ora afferma che le proprie organizzazioni hanno adottato misure per proteggerli dalla responsabilità personale, un terzo (34%) sente ancora di non avere le risorse per raggiungere i propri obiettivi di cybersecurity.

“L’intelligenza artificiale è passata da semplice concetto a elemento centrale, trasformando il modo in cui operano sia i difensori che gli attaccanti,” commenta Ryan Kalember, Chief Strategy Officer di Proofpoint. “I CISO ora affrontano una duplice responsabilità: possono sfruttare l’AI per rafforzare la loro postura di sicurezza, ma devono garantirne al contempo un uso etico e responsabile e questa ricerca di equilibrio li pone al centro del processo decisionale strategico. Ma l’AI è solo una delle tante forze che stanno rimodellando il loro ruolo: man mano che le minacce si intensificano e gli ambienti diventano più complessi, le aziende stanno rivalutando cosa significhi realmente la responsabilità della cybersecurity nell’impresa odierna.”

L'articolo Proofpoint: Allarme CISO italiani, l’84% teme un cyberattacco entro un anno, tra AI e burnout proviene da il blog della sicurezza informatica.

Il 27 agosto 2025 la Wikimedia Foundation, che gestisce Wikipedia, ha ricevuto una lettera ufficiale dalla Committee on Oversight and Government Reform della Camera dei Rappresentanti degli Stati Uniti.
La missiva, firmata da James Comer e Nancy Mace, mette la piattaforma sotto inchiesta e chiede la consegna di documenti, comunicazioni e, fatto ancora più delicato, i dati identificativi degli editor volontari che hanno scritto articoli ritenuti “anti-Israele”.

Una richiesta che fa tremare i pilastri non solo di Wikipedia, ma dell’intero ecosistema digitale: privacy degli utenti e libertà di espressione.

Il paradosso americano

Gli Stati Uniti amano definirsi “la patria della libertà di parola”, con il Primo Emendamento come bandiera. Eppure, ogni volta che entrano in gioco interessi geopolitici e alleanze strategiche, la libertà diventa improvvisamente negoziabile.

Questa indagine rappresenta l’ennesima contraddizione: da un lato si predica l’apertura e il diritto di esprimere opinioni, dall’altro si chiede a un’organizzazione privata di smascherare i suoi utenti, consegnando nomi, indirizzi IP e log di attività a un’istituzione governativa.

Di fatto, chiunque contribuisca a Wikipedia dovrebbe iniziare a chiedersi: “Se scrivo su un tema controverso, sto facendo divulgazione… o sto firmando la mia prossima convocazione davanti a un comitato congressuale?”.

Privacy sacrificata sull’altare della politica

Wikipedia vive di un principio fondamentale: la possibilità per migliaia di volontari, in tutto il mondo, di contribuire in forma libera e spesso anonima.
Se questa barriera venisse abbattuta, ogni contributo diventerebbe un potenziale rischio personale.

L’inchiesta del Congresso non si limita a voler analizzare eventuali campagne di disinformazione orchestrate da attori statali o universitari. Va oltre: pretende dati personali di cittadini che, nella maggior parte dei casi, hanno semplicemente partecipato al dibattito culturale.

E qui nasce il vero pericolo: quando la “lotta alla disinformazione” si trasforma in un pretesto per colpire il dissenso.

Il lato tecnico: come possono essere usati quei dati

Il dettaglio più preoccupante riguarda la natura delle informazioni richieste: IP, date di registrazione, log di attività, metadati di navigazione.
Per chi conosce le dinamiche della sorveglianza digitale, questo significa una cosa sola: tracciabilità totale.

• Un indirizzo IP consente di collegare l’attività online a un luogo fisico o a un provider.
• Incrociando IP con timestamp e user agent, si possono ricostruire abitudini, fasce orarie e persino dedurre profili comportamentali.
• L’analisi OSINT (Open Source Intelligence) permetterebbe poi di associare account Wikipedia ad altri profili social, forum o attività digitali, smascherando l’anonimato.

In pratica, con quei dati in mano, il Congresso potrebbe costruire dossier digitali sugli editor, identificandoli, mappando le loro attività e, se volesse, mettendoli in relazione con reti accademiche, gruppi politici o semplici comunità online.

Si aprirebbe così la strada a un controllo che non ha nulla a che vedere con la neutralità dell’informazione, ma molto con la sorveglianza di opinioni scomode.

Un precedente inquietante

Oggi si chiedono dati sugli editor che hanno scritto di Israele.
Domani potrebbe toccare a chi critica le lobby delle armi, le big tech, o chi denuncia falle nei sistemi di sorveglianza statunitensi.

Il problema non è difendere chi diffonde fake news,che restano una piaga reale, ma impedire che il concetto venga manipolato per silenziare opinioni scomode. Una volta aperto questo varco, richiuderlo sarà impossibile.

Verso un internet sorvegliato

La vicenda mette in luce un trend che ormai si sta consolidando: da spazio libero e anarchico, la rete rischia di trasformarsi in un territorio sorvegliato, dove governi e istituzioni reclamano accesso diretto ai dati degli utenti.

E l’ironia amara è che questa deriva arrivi proprio dagli Stati Uniti, che amano presentarsi come difensori globali della libertà di espressione.
Ma la domanda rimane: può davvero esistere libertà di parola, se ogni parola è tracciata, archiviata e usata contro chi la pronuncia?

Questa non è solo una storia che riguarda Wikipedia. È un campanello d’allarme per chiunque creda che privacy e libertà di espressione siano diritti fondamentali, non concessioni revocabili al primo tornaconto politico.

L'articolo Wikipedia nel mirino del Congresso USA: quando la libertà di espressione diventa “sorvegliata speciale” proviene da il blog della sicurezza informatica.

La scorsa settimana è emerso che degli hacker criminali avevano compromesso la piattaforma di automazione delle vendite Salesloft e rubato token OAuth e di aggiornamento dai clienti nel suo agente di intelligenza artificiale Drift, progettato per integrarsi con Salesforce. Come Google ha ora avvertito, l’attacco è stato diffuso e ha interessato i dati di Google Workspace.

SalesDrift è una piattaforma di terze parti per l’integrazione del chatbot Drift AI con un’istanza di Salesforce, consentendo alle organizzazioni di sincronizzare conversazioni, lead e ticket di supporto con il proprio CRM. Drift può anche integrarsi con una varietà di servizi per semplificare il processo, tra cui Salesforce (non correlato a Salesloft) e altre piattaforme (Slack, Google Workspace e altre).

Secondo Salesloft, l’attacco è avvenuto tra l’8 e il 18 agosto 2025. In seguito all’attacco, gli aggressori hanno ottenuto i token OAuth e di aggiornamento del client Drift utilizzati per l’integrazione con Salesforce, per poi utilizzarli per rubare dati da Salesforce. “Le indagini iniziali hanno rivelato che l’obiettivo principale dell’aggressore era il furto di credenziali, prendendo di mira specificamente informazioni sensibili come chiavi di accesso AWS, password e token di accesso associati a Snowflake”, si leggeva nella dichiarazione iniziale di Salesloft. “Abbiamo stabilito che questo incidente non ha avuto ripercussioni sui clienti che non utilizzano la nostra integrazione Drift-Salesforce. Sulla base delle nostre indagini in corso, non vi sono prove di attività dannose in corso correlate a questo incidente”.

Insieme ai colleghi di Salesforce, gli sviluppatori di Salesloft hanno revocato tutti gli accessi attivi e i token di aggiornamento per Drift. Inoltre, Salesforce ha rimosso l’app Drift da AppExchange in attesa delle indagini e delle garanzie di Salesloft sulla sicurezza della piattaforma.

L’attacco è stato condotto dal gruppo di hacker UNC6395, come riportato la scorsa settimana da Google Threat Intelligence (Mandiant) . Secondo i ricercatori, dopo aver ottenuto l’accesso a un’istanza di Salesforce, gli hacker hanno eseguito query SOQL per estrarre token di autenticazione, password e segreti dai ticket di supporto, il che ha permesso loro di proseguire l’attacco e compromettere altre piattaforme.

“GTIG ha scoperto che UNC6395 prende di mira credenziali sensibili, tra cui chiavi di accesso (AKIA) di Amazon Web Services (AWS), password e token di accesso associati a Snowflake”, ha scritto Google. “UNC6395 dimostra una buona consapevolezza della sicurezza operativa eliminando i processi di query, ma i log non sono stati interessati e le organizzazioni dovrebbero esaminare i log pertinenti per individuare indicatori di una violazione dei dati”.

Gli esperti hanno allegato indicatori di compromissione al loro rapporto e hanno osservato che gli aggressori hanno utilizzato Tor e provider di hosting come AWS e DigitalOcean per nascondere la propria infrastruttura. Le stringhe User-Agent associate al furto di dati includevano python-requests/2.32.4, Python/3.11, aiohttp/3.12.15 e, per gli strumenti personalizzati, Salesforce-Multi-Org-Fetcher/1.0 e Salesforce-CLI/1.0.

Google ha consigliato alle aziende che utilizzano Drift integrato con Salesforce di considerare dei compromessi per l’accesso ai propri dati Salesforce. Le aziende interessate sono state invitate ad adottare misure immediate per mitigare l’incidente. Quel che è peggio è che pochi giorni dopo si è scoperto che la fuga di dati era molto più grande di quanto inizialmente pensato. Gli esperti di Google hanno lanciato l’allarme: gli aggressori hanno utilizzato token OAuth rubati per accedere agli account email di Google Workspace e hanno rubato dati da istanze di Salesforce.

Il problema è che i token OAuth per l’integrazione di Drift Email sono stati compromessi e utilizzati da un aggressore il 9 agosto per accedere all’email di un “numero limitato” di account Google Workspace integrati direttamente con Drift.“Sulla base di nuove informazioni, questo problema non si è limitato all’integrazione di Salesforce con Salesloft Drift, ma ha avuto ripercussioni anche su altre integrazioni”, hanno spiegato i ricercatori. “Ora consigliamo a tutti i clienti di Salesloft Drift di considerare tutti i token di autenticazione archiviati o connessi alla piattaforma Drift come potenzialmente compromessi”.

Salesloft ha inoltre aggiornato il suo bollettino sulla sicurezza e ha dichiarato che Salesforce ha disabilitato l’integrazione di Drift con Salesforce, Slack e Pardot in attesa di un’indagine. Mentre Google attribuisce gli attacchi a un gruppo di hacker con identificativo UNC6395, ShinyHunters ha dichiarato a Bleeping Computer di essere dietro l’attacco. Tuttavia, gli hacker hanno successivamente affermato che l’incidente descritto da Google non era correlato a loro, poiché non avevano estratto dati dalle richieste di supporto.

Negli ultimi mesi, violazioni di dati simili che hanno coinvolto Salesforce e ShinyHunters hanno colpito Adidas , la compagnia aerea Qantas , la compagnia assicurativa Allianz Life, diversi marchi LVMH ( Louis Vuitton , Dior e Tiffany & Co), il sito web Cisco.com, nonché la casa di moda Chanel e l’azienda di gioielli danese Pandora.

ShinyHunters afferma inoltre di collaborare con il gruppo Scattered Spider, responsabile dell’accesso iniziale ai sistemi bersaglio. Gli aggressori ora si fanno chiamare Sp1d3rHunters, una combinazione dei nomi di entrambi i gruppi.

L'articolo Dall’AI chatbot al furto di dati globali: la falla Drift scuote Google Workspace proviene da il blog della sicurezza informatica.

Ogni giorno sentiamo parlare di privacy in ogni ambito della nostra vita, tanto che tale termine è entrato nel lessico comune. Ma cosa vuol dire veramente? Cosa succede quando ci iscriviamo a un social network oppure quando chiediamo di effettuare un’operazione bancaria? Anche senza rendercene conto, ogni giorno lasciamo ovunque dati personali, cioè delle tracce che parlano di noi e delle nostre preferenze.

Nel nostro ordinamento, tuttavia, alla parola privacy non corrisponde una definizione generalmente acquisita; essa, infatti, indica un concetto mutevole legato all’evolversi del contesto giuridico e sociale. Molto spesso, il termine privacy viene tradotto nel linguaggio comune con la parola riservatezza. In realtà, privacy e riservatezza sono due nozioni differenti. Mentre la riservatezza rappresenta il diritto alla propria sfera privata e ai propri dati personali, la privacy è un’estensione di tale diritto, poiché si concentra su tutti gli elementi che definiscono l’identità di un individuo, la sua storia, le sue abitudini e ogni status.

Ove legato alla tutela dei dati, la privacy estende il concetto di tutela, spostandolo dalla sfera privata alla dimensione sociale. È chiaro quindi che il diritto alla privacy include al suo interno quello alla riservatezza, attribuendo al soggetto che ne è titolare il potere di impedire che vengano divulgate informazioni sulla sua persona, nonché di controllare la raccolta e il trattamento delle informazioni stesse.

Affrontando la questione da un punto di vista storico, già con la Dichiarazione Universale dei Diritti Umani del 1948, all’art. 12, sebbene non esplicitato, si vieta ogni sorta di interferenza arbitraria nella riservatezza di ciascuno, garantendo al contempo una tutela legislativa contro eventuali ingerenze.

Anche nel territorio dell’Unione Europea, il legislatore è intervenuto a disciplinare la materia, dapprima con la Direttiva 95/46/CE, relativa alla tutela delle persone fisiche con riguardo al trattamento dei dati personali e alla libera circolazione degli stessi, e poi con la Carta dei diritti fondamentali dell’Unione Europea, dove all’art. 8 si attribuisce a ogni individuo il diritto alla protezione dei dati di carattere personale che lo riguardano.

Occorre tuttavia attendere il Regolamento (UE) 2016/679, noto come Regolamento Generale per la Protezione dei Dati Personali (GDPR), affinché si possa considerare un quadro normativo omogeneo in materia. All’interno del nostro ordinamento, le relative disposizioni sono confluite, da prima nel Codice in materia di protezione dei dati personali, di cui al D.Lgs. 196 del 2003 (Codice della Privacy). Questo codice è stato successivamente modificato dal D.Lgs. 101 del 2018, il quale ha armonizzato la normativa interna con quella sovranazionale.

Diversamente dal passato, la nuova disciplina sulla privacy si basa sul binomio responsabilizzazione/consapevolezza. L’accountability è a carico di chi gestisce i dati personali e li tratta da un lato, e della maggiore consapevolezza da parte dei titolari degli stessi dall’altro.

Ma alla fine, cosa si intende per dato personale? Per espressa previsione del GDPR, si definisce dato personale qualsiasi informazione riguardante una persona fisica identificata o identificabile, direttamente o indirettamente (ad es. un codice fiscale). Se in passato si parlava di dati sensibili e dati giudiziari, con il regolamento non è più corretto utilizzare questa espressione, ma si deve far riferimento agli artt. 9 e 10 della normativa europea che li sostituiscono.

In particolare, secondo l’art. 9 del regolamento, rientrano nella categoria dei dati personali non soltanto quelli che rivelano l’origine razziale o l’opinione politica, ma anche i dati genetici e biometrici intesi a identificare univocamente un soggetto fisico. L’art. 10 del regolamento europeo, invece, individua i dati personali relativi alle condanne penali e ai reati, nonché alle misure di sicurezza.

Di base, un dato personale è considerato trattato quando viene sottoposto a qualsiasi operazione o insieme di operazioni, compiute con processi automatizzati o anche senza. In particolare, ai sensi dell’art. 5 del GDPR, i dati devono essere trattati in modo lecito, corretto e trasparente. Devono essere raccolti per finalità ben determinate, minimizzando la quantità al trattamento necessario, e devono essere conservati in una forma che consenta l’identificazione degli interessati per un arco di tempo non superiore al conseguimento delle finalità.

Non meno importante è la previsione che deve garantire un’adeguata sicurezza, comprese misure tecniche e organizzative appropriate, per garantire l’integrità e la riservatezza da trattamenti non autorizzati, illeciti o accidentali.

Ma quando un trattamento del dato sarà lecito? Lo sarà solo se l’interessato ha espresso il consenso al trattamento per una o più specifiche finalità, oppure se il trattamento è necessario all’esecuzione di un contratto, per adempiere a un obbligo legale, per il perseguimento di un legittimo interesse del titolare del trattamento o di terzi, oppure per salvaguardare gli interessi vitali dell’interessato.

Come possiamo vedere, la scelta opportuna della base giuridica del trattamento è di fondamentale importanza per il titolare del trattamento, considerando che costui è responsabile della correttezza del trattamento.

Per tutelarsi in un contesto in cui la privacy è sempre più a rischio, le persone possono adottare diverse strategie. Innanzitutto, è fondamentale essere consapevoli delle informazioni personali che si condividono online. Questo include la revisione delle impostazioni sulla privacy sui social network e la limitazione della condivisione di dati sensibili, come indirizzi, numeri di telefono e informazioni finanziarie. Inoltre, è consigliabile utilizzare password forti e uniche per ogni account, attivare l’autenticazione a due fattori e monitorare regolarmente le proprie attività online per rilevare eventuali accessi non autorizzati. Infine, è importante informarsi sui diritti previsti dal GDPR, come il diritto di accesso e il diritto di rettifica, per poter esercitare un controllo attivo sui propri dati.

Pubblicare dati di altre persone senza il loro consenso può avere gravi conseguenze legali e morali. In primo luogo, si viola il diritto alla riservatezza e alla protezione dei dati personali, esponendo l’autore a sanzioni previste dal GDPR, che possono includere multe significative. Inoltre, la diffusione non autorizzata di informazioni personali può danneggiare la reputazione e la vita privata degli individui coinvolti, portando a conseguenze psicologiche e sociali. È quindi essenziale rispettare la privacy altrui e considerare le implicazioni etiche delle proprie azioni nel mondo digitale.

In un’epoca in cui la tecnologia permea ogni aspetto della nostra vita, la consapevolezza riguardo alla privacy e alla protezione dei dati personali è più cruciale che mai. La responsabilità non ricade solo sulle istituzioni e sulle aziende, ma anche su ciascuno di noi come individui. Adottare comportamenti proattivi per proteggere le proprie informazioni e rispettare la privacy degli altri non è solo un obbligo legale, ma un dovere morale. Solo attraverso una maggiore consapevolezza e responsabilizzazione possiamo costruire un ambiente digitale più sicuro e rispettoso, dove la privacy di ognuno è tutelata e valorizzata.

L'articolo Riservatezza vs Privacy: il concetto che tutti confondono (e perché è pericoloso) proviene da il blog della sicurezza informatica.