October 2021 - nexa - server-nexa.polito.it

Re: [nexa] A new high-end RISC-V 64 implementation(Under GPLv3)

by Alberto Cammozzo

Molto interessante. Per lo stesso progetto RISC-V, mi ha colpito l'implementazione bit-serial (SERV) che consente di piantare 6000 core in un FPGA. <https://www.hackster.io/news/new-corescore-world-record-crams-6-000-serv-ri…> Ciao, Alberto On 16/10/21 21:51, Giacomo Tesio wrote: > Ciao, > vi segnalo un progetto interessante di open hardware: > > Very high end RISC-V implementation – goal cloud server class > Out of order, super scalar, speculative > RV64-IMAFDCHB(V) > Up to 8 IPC (instructions per clock) peak, goal ~4 average on ALU heavy work > 2-way simultaneous multithreading capable > Multi-core > Early (low) dhrystone numbers: ~2 DMips/MHz - still a work in progress. Goal ~5 with working BTC > Currently boots Linux on an AWS-FPGA instance > GPL3 – dual licensing possible > > > https://moonbaseotago.github.io/talk/index.html > > https://github.com/MoonbaseOtago/vroom > > Si tratta del tipo di progetti su cui un Paese con un minimo di cultura cibernetica e > politica industriale potrebbe investire. > > Non l'Italia, naturalmente, che da noi la politica industriale consiste sempre nel > sovvenzionare i cantori del libero mercato. > > > Giacomo > > PS naturalmente il progetto in sé è ancora in una fase embrionale, > sebbene possa già eseguire Linux su una FPGA emulata. > > L'introduzione dell'esecuzione speculativa in una nuova CPU dopo Meltdown e Spectre > è andarsi a cercar grane col lanternino. > > Tuttavia secondo me rimane un punto di partenza interessante. > _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

Oct. 16, 2021

A new high-end RISC-V 64 implementation(Under GPLv3)

by Giacomo Tesio

Ciao, vi segnalo un progetto interessante di open hardware: Very high end RISC-V implementation – goal cloud server class Out of order, super scalar, speculative RV64-IMAFDCHB(V) Up to 8 IPC (instructions per clock) peak, goal ~4 average on ALU heavy work 2-way simultaneous multithreading capable Multi-core Early (low) dhrystone numbers: ~2 DMips/MHz - still a work in progress. Goal ~5 with working BTC Currently boots Linux on an AWS-FPGA instance GPL3 – dual licensing possible https://moonbaseotago.github.io/talk/index.html https://github.com/MoonbaseOtago/vroom Si tratta del tipo di progetti su cui un Paese con un minimo di cultura cibernetica e politica industriale potrebbe investire. Non l'Italia, naturalmente, che da noi la politica industriale consiste sempre nel sovvenzionare i cantori del libero mercato. Giacomo PS naturalmente il progetto in sé è ancora in una fase embrionale, sebbene possa già eseguire Linux su una FPGA emulata. L'introduzione dell'esecuzione speculativa in una nuova CPU dopo Meltdown e Spectre è andarsi a cercar grane col lanternino. Tuttavia secondo me rimane un punto di partenza interessante.

Oct. 16, 2021

Android Mobile OS Snooping By Samsung, Xiaomi, Huawei and Realme Handsets

by Giacomo Tesio

The privacy of mobile apps has been extensively studied, but much less attention has been paid to the privacy of the mobile OS itself. A mobile OS may communicate with servers to check for updates, send telemetry and so on. We undertake an in-depth analysis of the data sent by six variants of the Android OS, namely those developed by Samsung, Xiaomi, Huawei, Realme, LineageOS and /e/OS. We find that even when minimally configured and the handset is idle these vendorcustomized Android variants transmit substantial amounts of information to the OS developer and also to third-parties (Google, Microsoft, LinkedIn, Facebook etc) that have pre-installed system apps. While occasional communication with OS servers is to be expected, the observed data transmission goes well beyond this and raises a number of privacy concerns. There is no opt out from this data collection. [...] we find that sending persistent identifiers in connections is ubiquitous. Table I lists the main identifiers sent in connections on each handset. Some of these identifiers are long-lived, e.g. the IMEI (which is typically engraved on the SIM slot), hardware serial number and, on Huawei handsets, the device RSA cert [22]. These identifiers persist across factory resets of the device and are effectively permanent and indelible. Others, such as the Google Advertising Id and VAID, are user-resettable either manually or by a factory reset of the phone. But in practice that means they rarely change and act as strong device identifiers. Further, as we discuss in more detail below, most of these resettable identifiers can be relinked back to the device since long-lived identifiers are sent alongside them. [...] Additionally, Samsung, Xiaomi, Realme, Huawei, Heytap and Google also collect details of all apps installed on a handset. This is potentially more sensitive information since the set of apps installed is more likely to be unique to one handset, or a small number of handsets, and so act as a device fingerprint (especially when combined with device hardware/system configuration data). It is not clear why this data collection is needed [...] Samsung and Xiaomi both log data that can reveal user interactions occurring on a handset. Third-party system apps by Google and Microsoft also carry our event logging that can reveal user interactions. Heytap, Daily Motion and the mobile operator log events related to operation of their specific app. [...] The events logged include, for example, every opening and closing of an app window (“activities” in Android parlance) plus the duration a window is open. Since all window events appear to be logged, this can easily reveal detailed information on user handset usage. [...] Microsoft’s Swiftkey keyboard (used on the Huawei handset) also carries out extensive event logging [...] In particular, when the keyboard is used within an app then the app name, number of characters entered and an event timestamp are sent. In this way use, for example, of the searchbar, contacts and messaging apps is logged and so can easily reveal detailed information on user handset usage. [...] Several Samsung system apps use Google Analytics to log user interaction events, including windows/activities viewed plus duration and timestamp. [...] Google Play Services and the Google Play store collect large volumes of data from all of the handsets (see Figure 2). This has also been observed in other recent studies, which also note the opaque nature of this data collection (no documentation, binary encoded payloads, obfuscated code). From our discussions with Google we understand that they plan to publish documentation on this data collection/telemetry, but to date that has not happened. [...] In response to privacy concerns, identifiers used to track user behaviour are now often resettable [23]. For example, the Google Advertising Identifier (GAID) can be reset via the Settings app on an Android handset. The idea is that by resetting such an identifier a person effectively unlinks themselves from the data collected about them in the past and starts afresh. However, this aim is largely subverted as the data collected allows relinking of the new identifier to the same physical user/handset. We find that data collection allowing the potential for relinking is commonplace. [...] We find that typically multiple parties collect data from a handset. For example, on a Samsung handset Samsung, Google and Microsoft/LinkedIn all collect data. That raises the question of whether the data collected separately by these parties can be linked together (and of course combined with data from other sources). While we are not in a position to know whether such linking actually takes place, by inspection of the identifiers jointly collected by the parties we can see whether the potential exists for data linking [...] Continua con maggiori dettagli su: https://www.scss.tcd.ie/Doug.Leith/Android_privacy_report.pdf Giacomo

Oct. 16, 2021

Re: [nexa] Amazon copied products and rigged search results, documents show

by Roberto Resoli

Il 14/10/21 09:18, J.C. DE MARTIN ha scritto: > > https://www.reuters.com/investigates/special-report/amazon-india-rigging/ > Sullo stesso tema, da "TheMarkup": https://themarkup.org/amazons-advantage/2021/10/14/amazon-puts-its-own-bran… rob

Oct. 16, 2021

Re: [nexa] Facebook banned me for life because I created the tool Unfollow Everything.

by Roberto Resoli

Il 16/10/21 16:42, J.C. DE MARTIN ha scritto: > > https://slate.com/technology/2021/10/facebook-unfollow-everything-cease-des… Molto molto interessante, grazie. rob

Oct. 16, 2021

Re: [nexa] Facebook banned me for life because I created the tool Unfollow Everything.

by Stefano Quintarelli

forse quelle no, ma l'interoperabilità si. On 16/10/21 17:05, M. Fioretti wrote: > On Sat, Oct 16, 2021 16:42:00 PM +0200, J.C. DE MARTIN wrote: >> >> https://slate.com/technology/2021/10/facebook-unfollow-everything-cease-des… > > Grande. Grazie. Ora non vedo l'ora di sentire le spiegazioni di come > l'uso di norme antitrust, e ogni forma di "break up Facebook" avrebbe > il minimo effetto su azioni del genere. > > Marco >

Oct. 16, 2021

Re: [nexa] Facebook banned me for life because I created the tool Unfollow Everything.

by M. Fioretti

On Sat, Oct 16, 2021 16:42:00 PM +0200, J.C. DE MARTIN wrote: > > https://slate.com/technology/2021/10/facebook-unfollow-everything-cease-des… Grande. Grazie. Ora non vedo l'ora di sentire le spiegazioni di come l'uso di norme antitrust, e ogni forma di "break up Facebook" avrebbe il minimo effetto su azioni del genere. Marco -- Help me to continue my digital awareness blogging: https://stop.zona-m.net/christmas-2020-fundraising/

Oct. 16, 2021

Facebook banned me for life because I created the tool Unfollow Everything.

by J.C. DE MARTIN

https://slate.com/technology/2021/10/facebook-unfollow-everything-cease-des… (Sent from my wireless device; please excuse brevity and typos (if any))

Oct. 16, 2021

Re: [nexa] Amazon copied products and rigged search results, documents show

by Claudio Agosti

Seguitemi un attimo in questo volo pindarico, per piacere :) Dalla whistleblower di Facebook ( https://www.theguardian.com/commentisfree/2021/oct/08/facebook-frances-haug… ) dicono: " Zhang, in contrast, raised issues that Americans tend not to worry about: the fates of people beyond the United States" Cosa che non doveva stupirci*, perchè ogni sistema di content moderator, di raccomandazione, tende a specializzarsi per una nazione, o per una lingua (con effetti che potremmo chiamare di colonialismo digitale, particolarmente evidenti se avete letto An Ugly Truth https://www.nytimes.com/2021/07/09/books/review/the-ugly-truth-sheera-frenk…) Il fatto è che se gli enti regolatori ed i policy maker riflettono sull'influenza che queste piattaforme hanno sulla massa, ma questa influenza non è facile da misurare ne da attribuire. Le raccomandazioni controllate dall piattaforma, diciamo per il 50% dei risultati sono su base nazionale (dai quali si potrebbe inferire un trattamento favorevole per alcuni prodotti), ma poi ci sono altre fette di risultati che invece sono imputabili a ragioni diverse (regionalizzati, personalizzati, sconti limitati nel tempo, prodotti da smaltire, o A-B testing) Questo deve farci riflettere sulla difficoltà che ci deve essere nell'organizzare queste analisi. Più il sistema diventa personalizzato, e meno facilmente emergeranno evidenze di favoreggiamento. Per quanto riguarda Amazon, nel 2019 ho prodotto un tool (usato sinora molto al di sotto delle sue possibilità), che serve collezionare evidenze (quali prodotti amazon raccomanda in una pagina prodotto, e quali prodotti sono restituiti dopo una query di ricerca. per ogni prodotto sulla pagina, si prende il nome, l'id, merchant, il costo, e la foto). L'idea è che in modo passivo salvi quello che l'acquirente/analista sta facendo, così da poterle poi comparare. Poi una volta collezionate evidenze,si può cercare un eventuale favoreggiamento di prodotti. Ma senza comparare navigazioni equivalenti, non si può dichiarare quali siano i prodotti "soprendentemente molto presenti", da quelli momentanei, o personalizzati. Per chi volesse leggere un po', in homepage di https://amazon.tracking.exposed trovate 5 progetti di studenti, una tesi di master che collega la personalizzazione dello shopping ad articolo 22 GDRP, e poi con la Rai abbiamo girato un piccolo video che spiega un po' la personalizzazione ed i prezzi dinamici (perchè i prezzi cambiano, ma ufficialmente la responsabilità è dei venditori che applicano sconti, in modo molto granulare ed arbitrario). Per commentare sull'articolo condiviso da J.C: si parla ancora una volta di Stati Uniti. Chissà qui in Italia come sono le cose. L'unico modo per scoprirlo, è collezionare evidenze. Poi una volta che questo succede, o si fa open science (i dati sono disponibili liberamente) o gruppi di ricerca che volessero organizzare le loro collezioni, possono avere a disposizione metodi più riservati per scaricare i dati pertinenti alla loro collezione**. * Non ricordo se l'ho pubblicizata qui, ma organizzammo ad inizio pandemia, un'analisi collaborativa delle raccomandazioni di youtube. La metodologia era volta a raccogliere evidenze per confermare o smentire che la moderazione dei contenuti in inglese fosse migliore di quella in altre lingue. Il test venne in mente perchè Google aveva appena dichiarato che avrebbe "ridotto il reach" della disinformazione covid. La metodologia la trovate qui https://youtube.tracking.exposed/wetest/1/ dalla quale è poi scaturita questa pubblicazione https://www.springerprofessional.de/en/yttrex-crowdsourced-analysis-of-yout… (anche disponibile su arxiv); una cosa simile la possiamo pensare anche per Amazon ;) ** Questo almeno dovrebbe succedere nel mondo ideale, nel quale i nostri tool funzionano al 100% e fanno esattamente quello che ci si aspetta. Non è così semplice, ma, se quest'email vi solletica curiosità, possiamo provarci insieme e parlare di metodologie. ciao, Claudio On Thu, Oct 14, 2021 at 9:18 AM J.C. DE MARTIN <demartin(a)polito.it> wrote: > > https://www.reuters.com/investigates/special-report/amazon-india-rigging/ > > > (Sent from my wireless device; please excuse brevity and typos (if any)) > _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa > -- Claudio Agosti — https://tracking.exposed <https://facebook.tracking.exposed> twitter - https://twitter.com/@_vecna

Oct. 16, 2021

Paper: “Bugs in our Pockets: The Risks of Client-Side Scanning”

by J.C. DE MARTIN

https://regmedia.co.uk/2021/10/14/key_risks_paper.pdf Bugs in our Pockets: The Risks of Client-Side Scanning Embargoed until 0200 CET Oct 15 Ross Anderson Steven M. Bellovin Matt Blaze Jon Callas Peter G. Neumann Jeffrey I. Schiller Bruce Schneier Carmela Troncoso October 14, 2021 Executive Summary Whitfield Diffie Ronald L. Rivest Vanessa Teague Susan Landau Our increasing reliance on digital technology for personal, economic, and government affairs has made it essential to secure the communications and devices of private citizens, businesses, and governments. This has led to pervasive use of cryptography across society. Despite its evident advantages, law enforcement and national security agencies have argued that the spread of cryptography has hindered access to evidence and intelligence. Some in industry and government now advocate a new technology to access targeted data: client-side scanning (CSS). Instead of weakening encryption or providing law enforcement with backdoor keys to decrypt communications, CSS would enable on-device analysis of data in the clear. If targeted information were detected, its existence and, potentially, its source, would be revealed to the agencies; otherwise, little or no information would leave the client device. Its proponents claim that CSS is a solution to the encryption versus public safety debate: it offers privacy—in the sense of unimpeded end-to-end encryption—and the ability to successfully investigate serious crime. In this report, we argue that CSS neither guarantees efficacious crime prevention nor prevents surveillance. Indeed, the effect is the opposite. CSS by its nature creates serious security and privacy risks for all society while the assistance it can provide for law enforcement is at best problematic. There are multiple ways in which client-side scanning can fail, can be evaded, and can be abused. Its proponents want CSS to be installed on all devices, rather than installed covertly on the devices of suspects, or by court order on those of ex-offenders. But 1 universal deployment threatens the security of law-abiding citizens as well as law- breakers. Technically, CSS allows end-to-end encryption, but this is moot if the message has already been scanned for targeted content. In reality, CSS is bulk in- tercept, albeit automated and distributed. As CSS gives government agencies access to private content, it must be treated like wiretapping. In jurisdictions where bulk intercept is prohibited, bulk CSS must be prohibited as well. Although CSS is represented as protecting the security of communications, the technology can be repurposed as a general mass-surveillance tool. The fact that CSS is at least partly done on the client device is not, as its proponents claim, a security feature. Rather, it is a source of weakness. As most user devices have vulnerabilities, the surveillance and control capabilities provided by CSS can potentially be abused by many adversaries, from hostile state actors through criminals to users’ intimate partners. Moreover, the opacity of mobile operating systems makes it difficult to verify that CSS policies target only material whose illegality is uncontested. The introduction of CSS would be much more privacy invasive than previous proposals to weaken encryption. Rather than reading the content of encrypted com- munications, CSS gives law enforcement the ability to remotely search not just com- munications, but information stored on user devices. Introducing this powerful scanning technology on all user devices without fully understanding its vulnerabilities and thinking through the technical and policy con- sequences would be an extremely dangerous societal experiment. Given recent expe- rience in multiple countries of hostile-state interference in elections and referenda, it should be a national-security priority to resist attempts to spy on and influence law- abiding citizens. CSS makes law-abiding citizens more vulnerable with their personal devices searchable on an industrial scale. Plainly put, it is a dangerous technology. Even if deployed initially to scan for child sex-abuse material, content that is clearly illegal, there would be enormous pressure to expand its scope. We would then be hard-pressed to find any way to resist its expansion or to control abuse of the system. The ability of citizens to freely use digital devices, to create and store content, and to communicate with others depends strongly on our ability to feel safe in doing so. The introduction of scanning on our personal devices—devices that keep information from to-do notes to texts and photos from loved ones—tears at the heart of privacy of individual citizens. Such bulk surveillance can result in a significant chilling effect on freedom of speech and, indeed, on democracy itsel (Sent from my wireless device; please excuse brevity and typos (if any))

Oct. 15, 2021