Chrome OS annunciato per la seconda metà del 2010

July 8th, 2009 Giulio Rossetti Posted in Internet, OpenSource, Pensieri 4 Comments »

No Gravatar
Google Chrome
Image via Wikipedia

In alcuni casi è meglio non limitarsi a fornire informazioni di seconda mano, per questo riporto il testo integrale del post apparso ieri sull’Official Google Blog dal titolo Introducing the Google Chrome OS

It’s been an exciting nine months since we launched the Google Chrome browser. Already, over 30 million people use it regularly. We designed Google Chrome for people who live on the web — searching for information, checking email, catching up on the news, shopping or just staying in touch with friends. However, the operating systems that browsers run on were designed in an era where there was no web. So today, we’re announcing a new project that’s a natural extension of Google Chrome — the Google Chrome Operating System. It’s our attempt to re-think what operating systems should be.

Google Chrome OS is an open source, lightweight operating system that will initially be targeted at netbooks. Later this year we will open-source its code, and netbooks running Google Chrome OS will be available for consumers in the second half of 2010. Because we’re already talking to partners about the project, and we’ll soon be working with the open source community, we wanted to share our vision now so everyone understands what we are trying to achieve.

Speed, simplicity and security are the key aspects of Google Chrome OS. We’re designing the OS to be fast and lightweight, to start up and get you onto the web in a few seconds. The user interface is minimal to stay out of your way, and most of the user experience takes place on the web. And as we did for the Google Chrome browser, we are going back to the basics and completely redesigning the underlying security architecture of the OS so that users don’t have to deal with viruses, malware and security updates. It should just work.

Google Chrome OS will run on both x86 as well as ARM chips and we are working with multiple OEMs to bring a number of netbooks to market next year. The software architecture is simple — Google Chrome running within a new windowing system on top of a Linux kernel. For application developers, the web is the platform. All web-based applications will automatically work and new applications can be written using your favorite web technologies. And of course, these apps will run not only on Google Chrome OS, but on any standards-based browser on Windows, Mac and Linux thereby giving developers the largest user base of any platform.

Google Chrome OS is a new project, separate from Android. Android was designed from the beginning to work across a variety of devices from phones to set-top boxes to netbooks. Google Chrome OS is being created for people who spend most of their time on the web, and is being designed to power computers ranging from small netbooks to full-size desktop systems. While there are areas where Google Chrome OS and Android overlap, we believe choice will drive innovation for the benefit of everyone, including Google.

We hear a lot from our users and their message is clear — computers need to get better. People want to get to their email instantly, without wasting time waiting for their computers to boot and browsers to start up. They want their computers to always run as fast as when they first bought them. They want their data to be accessible to them wherever they are and not have to worry about losing their computer or forgetting to back up files. Even more importantly, they don’t want to spend hours configuring their computers to work with every new piece of hardware, or have to worry about constant software updates. And any time our users have a better computing experience, Google benefits as well by having happier users who are more likely to spend time on the Internet.

We have a lot of work to do, and we’re definitely going to need a lot of help from the open source community to accomplish this vision. We’re excited for what’s to come and we hope you are too. Stay tuned for more updates in the fall and have a great summer.

Sinceramente sono abbastanza “soddisfatto” da questa decisione di Google di entrare nel mercato dei SO (in modo open a quanto pare, e questo rinforza la mia soddisfazione). L’unico effetto negativo evidente è che Orwell quando scrisse 1984 non immaginava minimamente che il “Grande Fratello” potesse essere bene accolto dalla popolazione stessa.

Nulla da ridire sui servizi offerti da “Big G”, di cui sono un utilizzatore sconsiderato da tempo, ma effettivamente c’è da riconoscere che al giorno d’oggi le informazioni in mano a tale azienda sono talmente tante e talmente capillari che chiunque di noi può considerarsi “schedato e\o schedabile” senza troppi problemi.

Ai posteri l’ardua sentenza.. intanto aspettiamo per valutare la portata effettiva del progetto..

Reblog this post [with Zemanta]

Popularity: 6% [?]

AddThis Social Bookmark Button

Facebook: un analisi (personale) della privacy offerta dalle API

June 20th, 2009 Giulio Rossetti Posted in Internet, Pensieri, Programmazione, Security No Comments »

No Gravatar
Facebook's new homepage features a login form ...
Image via Wikipedia

A seguito del post di ieri (relativo alla scarsa privacy offerta da Facebook) ho iniziato, da bravo informatico, a interrogarmi su alcune implicazioni di quanto riportato.

Premetto che quelle che propongo qui di seguito sono solo supposizioni e non vogliono essere interpretate come realtà assoluta – invito anzi chi abbia voglia a discuterne nei commenti – e che ho deciso di scrivere questo post solo ed esclusivamente per mettere a fuoco qualche dettaglio che può essermi sfuggito.

Riepilogando:  ieri abbiamo visto che, tramite le API offerte da FB agli sviluppatori e un po’ di colpo d’occhio, è possibile ottenere pressappoco tutte(*) le informazioni personali che un qualsiasi utente – pur impostando il proprio profilo come privato – da in pasto al social network in questione.

Fino a qui diciamo che siamo nella “norma”. Il tutto non può essere definito un bug ne una “lack of security” poiché proprio nei termini d’uso delle API del servizio si esprime esplicitamente che i dati ricavati con tale approccio debbano essere cancellati entro le 24 ore. Questo implica che sostanzialmente il tutto era previsto e accettato al momento della pubblicazione delle API.

Ho detto nella “norma”: immagino che qui il concetto sia abbastanza vago e si presti ad interpretazioni, diciamo solo che – almeno dal mio punto di vista – l’accesso a tutte le informazioni di un utenza non hanno molto significato per uno sviluppatore di applicazioni per tale piattaforma.

In fin dei conti a quale applicazione è necessario sapere quali sono i nostri percorsi di studi\interessi musicali\orientamento politico\ etc. etc. ? Questi dati possono essere al più utili a chi ha intenzione di fare delle analisi statistiche e raccolta di dati a fine commerciale (analisi che non potrebbero in ogni caso essere fatte proprio per il limite di “vita” imposto da Fb per i dati ottenuti proprio come dicevo precedentemente).

Diciamo quindi che molto probabilmente è stata fatta una scelta sbagliata relativa alle informazioni da rendere disponibili sugli utenti per salvaguardarne la privacy. Errore non proprio da nulla a mio avviso.

Vediamo inoltre che, per assurdo indagando su una persona in questo modo si possono ottenere tutte le informazioni sui contatti a questa collegati – e via dicendo con un effetto a cascata.

Avevo espresso qualche dubbio a fine articolo relativamente alla possibilità offerta da breve da FB di impostare un nome al nostro account, impostando un url rewriting per rendere più leggibile l’indirizzo della pagina del nostro profilo, e alla possibile “risoluzione” trasversale di questo problema di privacy.

Inizialmente l’idea mi aeva quasi convinto: in fin dei conti se riesco a riscrivere le url di tutti i profili nascondendo le informazioni sull’id del contatto tutte le interrogazioni che posso fare tramite un applicazione scritta con le API prevedono che questi ne autorizzi l’uso. Mi spiego meglio, se io utente non proprietario del contatto non conosco l’id non posso manualmente creare una query ad-hoc. Mentre, al contrario, se sono il proprietario dell’account avrò salvato da qualche parte il mio id (in sessione, in un cookie…) quindi potrò fornirlo di mia volontà all’applicazione.

Che poi possano essere comunque scritte applicazioni “malevole e impiccione” è un altro paio di maniche – fatto stà che l’utente ha in ogni caso modo di non essere passivamente soggetto a indagini mirate. Magra consolazione.

L’idea di nascondere l’id in effetti non era male – unico neo convertire tutti gli account vecchi senza “nome” facendo pressione sugli utenti finali presentando tale possibilità come un semplice abbellimento (si è parlato spesso di “fancy url”).

In ogni caso, purtroppo, seppure la strada era percorribile e forse la più rapida – di certo non la più sicura, ma ovviamente quella che garantiva la migliore retrocompatibilità con le applicazioni già sviluppate  – questa è stata interrotta a metà.

Ebbene si la riscrittura delle url vale solo per la pagina del profilo e non per tutti i link che puntano ad essa. Ad esempio i commenti lasciati hanno ancora un link contente l’id e ciò accade anche per i link per l’invio di messaggi di posta e compagina bella.

Quindi a quanto pare o la “soluzione” è stata percorsa a metà o molto probabilmente l’interesse alla privacy degli utenti è merce più rara di quella che solitamente si ricerca nel comune pensare.

Cosa dire… le soluzioni ci sarebbero, e alcune anche molto ma molto banali – già la scomparsa degli id visibili sarebbe un notevole passo avanti.

(*) Ieri ho parlato solo delle foto perché in effetti mi sembrava poco opportuno dare direttamente la query per ottenere informazioni personali ma, usando la struttura delle tabelle presente nel wiki ufficiale per gli sviluppatori di applicazioni per facebook non ci vuole molto a scriverne di banali per effettuare tali tipologie di ricerche…

Reblog this post [with Zemanta]

Popularity: 7% [?]

AddThis Social Bookmark Button

Facebook: Privacy? Siamo proprio sicuri? Come visualizzare Album di profili privati

June 19th, 2009 Giulio Rossetti Posted in HowTo, Internet, Pensieri, Programmazione, Security 16 Comments »

No Gravatar
Facebook, Inc.
Image via Wikipedia

Raramente ho parlato di Facebook, molto raramente a dirla tutta, e questo post vuole essere in netta contro tendenza.

[Disclaimer]

Espongo solo ed esclusivamente informazioni che sicuramente sono già di dominio pubblico, non si tratti di truchi, bug o altri eventuali errori o hack. L’eticità di quanto descrivo è strettamente correlata ai valori morali di chi decide o meno di testare quanto segue.

Per inciso: fate come volete, io non mi assumo responsabilità :P questa vuole essere solo una mini guida relativa all’interrogazione di base dei servizi offerti dalle API di Facebook. Il mio parere lo esprimerò in calce al post ora iniziamo con il procedimento.

[Fine Disclaimer]

Innanzitutto per poter far un test delle funzionalità offerte dalle API di Facebook andiamo all’indirizzo:

http://developers.facebook.com/tools.php

Ci troveremo davanti alla Console di collaudo API. Il metodo che ci interessa – per interagire con il database – è:

fql.query

Selezionato tale metodo non ci rimane che inserire la seguente, banalissima query:

SELECT name, link FROM album WHERE owner= ********

Dove al posto degli asterischi deve essere inserito l’id dell’utente facebook di cui siamo interessati a visualizzare gli album fotografici. Tale id può essere trovato, ad esempio, nel link per richiedere l’amicizia ad un contatto.

Verrà quindi visualizzato sulla destra il risultato della query effettuata contenente nome dell’album e relativo indirizzo (per inciso: nel link compare un escaping del tipo “& amp;id=” dopo aver fatto un cut-paste del link cancellate “amp;” dall’indirizzo ottenuto altrimenti, ovviamente mi verrebbe da dire, otterrete un errore)

[Considerazioni]

Questo è un esempio banale di come le policy relative alla Privacy degli utenti su Facebook siano relativamente molto deboli e permissive. Come già detto non si tratta di un bug – sarebbe tale se al posto di ottenere tali informazioni potessi anche cancellare e\o modificare il contenuto del db – ma di una scelta probabilmente obbligata dovuta alla necessità che terzi sviluppassero applicazioni per la piattaforma.

Pensate ad esempio a tutte le applicazioni che usano le vostre foto per fare collage o similari. In qualche modo devono poter accedere a tali informazioni e queste API sono il modo che FB mette a disposizione. Nulla di più nulla di meno. Lascia un po’ perplessi il fatto che siano disponibili praticamente a tutti (vera manna per programmatori ma inutili ad un utente finale) e messe li in bella mostra con tanto di piattaforma di testing integrata…

Per il resto come vi dicevo l’argomento è già stato trattato su altri blog e non è una novità (girellando mi accorgo ora che se ne era riparlato negli stessi termini anche qui ad esempio) ^_^

Ovviamente chi ha tempo da perderci si renderà conto che con le nuove url personalizzate non va… ma da qualche parte sarannò pur salvate no? [Questo ve lo lascio come compito per casa :P ]

Che dire “Grandi poteri portano a grandi responsabilità” (cit.) non abusatente e rispettate l’imperativo categorico della vostra morale…

[EDIT] Questa risorsa potrebbe esservi piacevolmente utile..

http://wiki.developers.facebook.com/index.php/FQL_Tables

Reblog this post [with Zemanta]

Popularity: 77% [?]

AddThis Social Bookmark Button