person:dan boneh

  • A Critical Look at Decentralized Personal Data Architectures
    by Arvind Narayanan, Vincent Toubiana, Solon Barocas, Helen Nissenbaum, Dan Boneh
    http://arxiv.org/abs/1202.4503

    Developers, regulators, and consumer advocates have looked to alternative decentralized architectures as the natural response to threats posed by these centralized services. The result has been a great variety of solutions (...) [such as] distributed social networks. And yet, for all these efforts, decentralized personal data architectures have seen little adoption.
    This position paper attempts to account for these failures, challenging the accepted wisdom in the web community on the feasibility and desirability of these approaches.

    #réseaux_sociaux #internet #histoire #centralisation

    • L’article « A Critical Look at Decentralized Personal Data Architectures » est un court résumé des problèmes que pose la conception d’un rézosocio décentralisé ou réparti. Les auteurs notent à juste titre que le problème est difficile et que les projets issus d’un bistrot et spécifiés en cinq minutes sur un coin de table n’avaient aucune chance d’affronter réellement Facebook ou Twitter. L’article décrit bien ces difficultés et les problèmes que cela pose (dans mon exposé à Pas Sage en Seine, je mentionnais uniquement le problème de la découverte mais il y en a d’autres). Ils notent également que les propriétés qu’on attend d’un rézosocio sont souvent contradictoires et qu’il va falloir faire des choix.

      Les auteurs critiquent à juste titre la confusion fréquente qui est faite entre caractéristiques techniques d’un système et les valeurs qu’on défend.

      L’article étant assez court, pas mal de points ne sont traités que sommairement. Par exemple, les auteurs critiquent les systèmes décentralisés comme obligeant M. Michu a installer et à gérer son propre serveur, oubliant complètement qu’on peut parfaitement utiliser des serveurs gérés par d’autres (associations, entreprises à but lucratif, groupes de copains, etc). Tous les systèmes décentralisés (à commencer par le courrier électronique) avaient pourtant cette possibilité depuis longemps.

      L’article erre aussi parfois vers la caricature lorsqu’il explique qu’on ne peut jamais avoir un contrôle complet sur ses données, laissant entendre que, dans ce cas, autant laisser tomber et aimer Facebook. L’idée qu’on puisse vouloir limiter les dégâts (sans pour autant avoir un contrôle complet) ne semble pas mentionnée.

      Autre manque, l’idée d’éducation et d’évolution. Pour les auteurs, la mentalité actuelle de M. Michu semble une loi naturelle, non susceptible de changement (« M. Michu s’en fiche de la vie privée »).

  • The Most Dangerous Code in the World : Validating SSL Certificates in Non-Browser Software par Martin Georgiev, Subodh Iyengar, Suman Jana, Rishita Anubhai, Dan Boneh et Vitaly Shmatikov

    Une excellente étude sur les vulnérabilités des applications utilisant #TLS (autrefois nommé #SSL), à l’exclusion des navigateurs Web. Des tas d’applications parfois peu connues et discrètes (par exemple pour réaliser la mise à jour des logiciels d’un système) utilisent, comme les navigateurs Web, TLS pour se protéger contre un méchant qui essaierait de détourner le trafic vers un autre serveur que celui visé. Mais, contrairement aux navigateurs Web, ces applications, souvent critiques (paiement entre cyber-marchands, par exemple) n’ont guère été étudiées et ont des vulnérabilités souvent énormes, permettant à un attaquant de se faire passer pour le serveur légitime, malgré TLS.

    Pour ne donner qu’un exemple (mais un des plus beaux), la bibliothèque #cURL, très utilisée par d’innombrables applications, a un paramètre CURLOPT_SSL_VERIFYHOST. La documentation dit bien qu’il doit être mis à 2 (sa valeur par défaut) pour que le nom soit vérifié et à 1 pour couper la vérification. Bien des programmes écrits dans des langages sans typage fort (comme PHP), mettent ce paramètre à « true », donc à 1, coupant ainsi la validation...

    Les auteurs de l’article, après avoir cassé la sécurité de TLS dans des dizaines d’applications, suggèrent des API mieux documentées, plus claires et de plus haut niveau, pour diminuer le risque que les programmeurs se trompent.

    http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf