[Je travaille chez Google, mais je n’ai aucune information interne sur cette décision et ce qui suit est un commentaire personnel qui n'engage pas mon employeur.]
Car en effet, et comme dit, certains services restant accessibles, l'une des clefs reste valide pour ces cas là. Mais le développeur qui proposera un tel accès sera facturé dès la première connexion.
Ce n’est pas ce que dit l’article d’AlienBob.
L’accès à safe-browsing (et autres services qui nécessitent de contacter les serveurs de Google sans authentifier l’utilisateur) restera possible avec une API key et un certain quota d’utilisation gratuit. Par contre, les mainteneurs de distributions ont bénéficié jusqu’à présent d’une augmentation de ce quota, en raison du large nombre d’utilisateur. AlienBob n’est pas sûr pour l’instant de si ce quota élargi sera maintenu après le 15 mars, mais Google n’a pas prétendu qu’il sera restreint, et la communication envoyée ne concernait ni cette API, ni la question de la gratuité. Par ailleurs, AlienBob indique dans les commentaires de son propre article qu’il va finalement attendre de voir ce qu’il en est du quota et de l’usage en pratique avant de décider s’il force les distributions dérivées à obtenir leur propre API key. A priori, il devrait être possible aux mainteneurs de ces distributions de demander un quota élargi au besoin pour leur propre clé.
En revanche, l’accès à Cloud Sync (et autres APIs nécessitant un Client-ID, ie. accédant à des données personnelles de l’utilisateur) sera coupé purement et simplement. Google invoque des raisons de sécurité des données. On lit entre les lignes une volonté de changer les mécanismes de sécurité à moyen terme, pour une version qui ne serait sans doute plus compatible avec le modèle actuel, mais ils ne donnent pas plus de détails à part qu’il n’y a à leur connaissance pas eu d’incident de sécurité (donc que la faille, s’il y en une, n’a pas été exploitée en pratique). Là il n’est pas question de coût du tout, des intégrateurs de ChromiumOS ont demandé sur le thread chrome-packagers s’ils pouvaient payer pour continuer d’avoir accès, et la réponse a été clairement non. Ceux dans la pire situation ne sont pas les fabricants de SmartTV mais les vendeurs de portables sous ChromiumOS (à part pour les revendeurs officiels comme Acer et Samsung), parce que leurs utilisateurs ne pourront plus se connecter du tout à leur ordi !
Je trouve également très frustrant le manque de transparence sur ce changement brutal, mais s’il s’agit effectivement d’une faille potentielle mais pas exploitée, on peut comprendre la grande prudence à ne pas communiquer plus de détails.
# Précisions : gratuité et sécurité
Posté par MrLapinot (site web personnel) . En réponse au journal AlienBob et les dédales de Chromium sous Slackware. Évalué à 10.
[Je travaille chez Google, mais je n’ai aucune information interne sur cette décision et ce qui suit est un commentaire personnel qui n'engage pas mon employeur.]
Ce n’est pas ce que dit l’article d’AlienBob.
L’accès à safe-browsing (et autres services qui nécessitent de contacter les serveurs de Google sans authentifier l’utilisateur) restera possible avec une API key et un certain quota d’utilisation gratuit. Par contre, les mainteneurs de distributions ont bénéficié jusqu’à présent d’une augmentation de ce quota, en raison du large nombre d’utilisateur. AlienBob n’est pas sûr pour l’instant de si ce quota élargi sera maintenu après le 15 mars, mais Google n’a pas prétendu qu’il sera restreint, et la communication envoyée ne concernait ni cette API, ni la question de la gratuité. Par ailleurs, AlienBob indique dans les commentaires de son propre article qu’il va finalement attendre de voir ce qu’il en est du quota et de l’usage en pratique avant de décider s’il force les distributions dérivées à obtenir leur propre API key. A priori, il devrait être possible aux mainteneurs de ces distributions de demander un quota élargi au besoin pour leur propre clé.
En revanche, l’accès à Cloud Sync (et autres APIs nécessitant un Client-ID, ie. accédant à des données personnelles de l’utilisateur) sera coupé purement et simplement. Google invoque des raisons de sécurité des données. On lit entre les lignes une volonté de changer les mécanismes de sécurité à moyen terme, pour une version qui ne serait sans doute plus compatible avec le modèle actuel, mais ils ne donnent pas plus de détails à part qu’il n’y a à leur connaissance pas eu d’incident de sécurité (donc que la faille, s’il y en une, n’a pas été exploitée en pratique). Là il n’est pas question de coût du tout, des intégrateurs de ChromiumOS ont demandé sur le thread chrome-packagers s’ils pouvaient payer pour continuer d’avoir accès, et la réponse a été clairement non. Ceux dans la pire situation ne sont pas les fabricants de SmartTV mais les vendeurs de portables sous ChromiumOS (à part pour les revendeurs officiels comme Acer et Samsung), parce que leurs utilisateurs ne pourront plus se connecter du tout à leur ordi !
Je trouve également très frustrant le manque de transparence sur ce changement brutal, mais s’il s’agit effectivement d’une faille potentielle mais pas exploitée, on peut comprendre la grande prudence à ne pas communiquer plus de détails.