L'idée qu'une appli ne puisse utiliser les contacts que localement leur est totalement étrangère.
Je ne comprends pas ce qui te fait dire ça, ils n'ont juste pas ce niveau de granularité. Ce qu'ils peuvent garantir à l'utilisateur, c'est si oui ou non l'appli a accès aux contacts. Dès que l'appli a accès aux contacts, c'est évident que tu ne peux plus rien garantir: peut-être que l'appli ne fait rien de ces données, peut-être qu'elle fait un calcul en local et c'est tout, peut-être qu'elle balance tout en clair sur ses serveurs, peut-être qu'elle fait remonter les données après avoir caché les infos dans des paquets qui ont l'air innocent... À moins d'analyser en détail le code de l'appli, tu ne peux rien garantir. D'où le niveau de permission qui me semble tout à fait logique: permettez-vous à l'appli d'accéder à vos contacts et d'en faire ce que le développeur veut bien en faire?
Ce que je n'ai pas compris, c'est si le sujet du conflit vient de la permission READ, auquel cas c'est à mon avis le dev qui est complètement responsable, ou si Google a en plus une couche d'analyse du code qui lui a fait penser à tort que les données issues des contacts était envoyée sur un serveur tiers. Là, sans analyser le truc en détail, c'est dur de conclure. Possibilité 1: Le dev dit que l'analyseur de code de Google a picolé et que le système d'appel est foireux, c'est bien possible. Possibilité 2: Le dev est démoniaque et remontait bien les contacts sur un serveur Ouzbeck par un moyen détourné, il s'est fait gauler par l'analyse du code et a monté un bateau pour se justifier (ça me semble peu probable, mais on ne sait jamais, je ne connais pas ce gars-là). Possibilité 3: il y a une faille de sécu qui fait que la remontée des contacts est théoriquement possible, bien que ça ne soit pas la volonté du dev. Honnêtement, ça ne me parait pas impossible, l'appli manipule des flux venant de sources non contrôlées, et les attaques par buffer overflow et autres, c'est réel.
En gros, comme on n'a qu'une version de l'histoire, on peut conclure que "c'est aussi simple que ça", mais ça ne parait pas impossible que ça ne soit pas aussi simple que ça.
Dans tous les cas, le workflow de Google semble être typique d'une entité en position de monopole: si tu fais la moindre erreur (ou que Google fait la moindre erreur), t'es ban sans discussion, et derrière le service pour rectifier est merdique. On ne peut pas donner tort à l'auteur sur le fait qu'ils auraient très bien pu ne pas accepter la mise à jour et laisser la version précédente dans leur store.
[^] # Re: Description objective du problème?
Posté par arnaudus . En réponse au journal Google retire Conversations du magasin Play (Play Store). Évalué à 6.
Je ne comprends pas ce qui te fait dire ça, ils n'ont juste pas ce niveau de granularité. Ce qu'ils peuvent garantir à l'utilisateur, c'est si oui ou non l'appli a accès aux contacts. Dès que l'appli a accès aux contacts, c'est évident que tu ne peux plus rien garantir: peut-être que l'appli ne fait rien de ces données, peut-être qu'elle fait un calcul en local et c'est tout, peut-être qu'elle balance tout en clair sur ses serveurs, peut-être qu'elle fait remonter les données après avoir caché les infos dans des paquets qui ont l'air innocent... À moins d'analyser en détail le code de l'appli, tu ne peux rien garantir. D'où le niveau de permission qui me semble tout à fait logique: permettez-vous à l'appli d'accéder à vos contacts et d'en faire ce que le développeur veut bien en faire?
Ce que je n'ai pas compris, c'est si le sujet du conflit vient de la permission READ, auquel cas c'est à mon avis le dev qui est complètement responsable, ou si Google a en plus une couche d'analyse du code qui lui a fait penser à tort que les données issues des contacts était envoyée sur un serveur tiers. Là, sans analyser le truc en détail, c'est dur de conclure. Possibilité 1: Le dev dit que l'analyseur de code de Google a picolé et que le système d'appel est foireux, c'est bien possible. Possibilité 2: Le dev est démoniaque et remontait bien les contacts sur un serveur Ouzbeck par un moyen détourné, il s'est fait gauler par l'analyse du code et a monté un bateau pour se justifier (ça me semble peu probable, mais on ne sait jamais, je ne connais pas ce gars-là). Possibilité 3: il y a une faille de sécu qui fait que la remontée des contacts est théoriquement possible, bien que ça ne soit pas la volonté du dev. Honnêtement, ça ne me parait pas impossible, l'appli manipule des flux venant de sources non contrôlées, et les attaques par buffer overflow et autres, c'est réel.
En gros, comme on n'a qu'une version de l'histoire, on peut conclure que "c'est aussi simple que ça", mais ça ne parait pas impossible que ça ne soit pas aussi simple que ça.
Dans tous les cas, le workflow de Google semble être typique d'une entité en position de monopole: si tu fais la moindre erreur (ou que Google fait la moindre erreur), t'es ban sans discussion, et derrière le service pour rectifier est merdique. On ne peut pas donner tort à l'auteur sur le fait qu'ils auraient très bien pu ne pas accepter la mise à jour et laisser la version précédente dans leur store.