Le plus bizarre pour moi, est que jusqu'à récemment la QdN n'était même pas une association loi 1901. Apparemment ça a changé récemment.
Concrètement ça m'avait toujours gêné que des mecs réclament de l'argent sans qu'il n'y ait d'association derrière. Ça voulait dire pas d'obligation d'avoir un trésorier, et donc personne officiellement responsable de tenir les comptes… On mettait tout simplement son argent dans une boîte noire.
Maintenant que ça n'est plus le cas, on peut peut-être demander à voir leur budget et leurs comptes?
C'est clairement une meilleure méthode. Une boîte munie d'un pare-feu correct va très facilement détecter les paquets ssh et les filtrer. Je le sais car j'en ai déjà fait les frais: ssh, ça se voit, même sur le port 443.
En faisant du ssh sur ssl, le flux passe pour une connection ssl anodine (ce qu'il est, d'ailleurs) et on risque beaucoup moins de se faire prendre. À priori, pour contrer cela, il faudrait être capable de reconnaître l'utilisation du CONNECT, mais comme ce CONNECT se fait seulement après établissement de la connection SSL, je doute que cela soit possible facilement.
Au vu des liens que tu donnes, j'imagine qu'il mérite d'être signalé qu'il existe au moins une méthode permettant de se passer de patcher apache: passer par stunnel. J'en ai fait un petit article (en anglais) 1.
Le système en place n'est finalement pas vraiment différent avec chaque application qui tourne sous son propre utilisateur, dans son "bac à sable", et qui doit déclarer des permissions pour utiliser les divers éléments du système.
Toi, tu voudrais imposer en plus des catégories dont les droits sont restreints par défaut. À première vue, ça limite aussi: Pour reprendre ton exemple, si je fais un jeu multi-joueur basé sur un échange de sms, j'ai plus le droit de le classer dans la catégorie "jeux", c'est dommage. Mais l'idée me plait, je me permet de la décliner: une possibilité serait que Google ajoute une propriété obligatoire dans le Manifest.xml (genre applicationType) et que le processus d'installation notifie l'utilisateur si une application d'une certaine catégorie utilise des permissions suspectes, avec un pop-up du style: "Cette application utilise des permissions peu habituelles pour sa catégorie. Il vous est recommandé d'être vigilant à son égard. Annuler/Continuer".
Le problème, c'est qu'en limitant ce que tu peux émettre, tu limites aussi en bien les développeurs. Je te donne l'exemple de l'appli que j'ai codé (libre, dispo sur https://code.google.com/p/talkmyphone/).
Celle-ci permet de contrôler son téléphone via jabber: tu en fais un de tes contacts (tu lui crées un compte au préalable) et tu peux, en discutant avec, le commander à distance (envoi/récupération de sms, position gps, état de la batterie etc...). C'est super utile de pouvoir agir à distance sur le téléphone, mais quand tu réfléchis cette appli agit de la même manière qu'un troyen. Quelques modifications suffiraient à la camoufler pour donner un accès presque total et invisible au téléphone à quelqu'un de malveillant. Dans la même veine, l'accès à la carte SIM et au hardware ID peuvent être utile si on vole le téléphone (par exemple HTC permet sur son site de rendre inutilisables les téléphones déclarés volés, je pense qu'il est possible qu'ils utilisent cela).
Que veux-tu faire vis à vis de cela? Si tu empêches de le faire, mon application n'existe plus. Si au contraire tu le permets, tu ouvres la porte aux programmes malveillants. Google choisit d'ouvrir plus de possibilités. Personnellement je ne m'en plains pas, je préfère plus de liberté même si cela implique plus de risques. Aux utilisateurs de ne pas installer n'importe quoi et aux développeurs de gagner leur confiance.
"Google vend les données personnelles des utilisateurs. Du coup, sur Android ils sont obligés de laisser un accès à ces données à certaines applications. Ensuite que ces accès soient détournés ne m'étonne qu'à moitié."
Cette partie de ton commentaire me semble techniquement fausse et lourde de raccourcis. Ayant développé sous Android, je me permet de corriger.
Je vais passer rapidement sur l'affirmation "Google vend les données personnelles des utilisateurs", car je ne dispose pas de preuves de leur honnêteté. D'après leurs conditions générales d'utilisation, s'ils utilisent bien ces données personnelles pour cibler leurs pubs, ils ne sont pas sensés commercialiser ces données.
C'est surtout la deuxième phrase qui me fait tiquer: "Du coup, sur Android ils sont obligés de laisser un accès à ces données à certaines applications". L'article dit: "they transmit information on the device's location, its hardware ID and SIM card back to the remote computer". Le fait que ces informations soient disponibles aux applications n'a rien à voir avec la politique de Google vis à vis des données personnelles, il a plus à voir avec le bon fonctionnement de celles-ci. Si une appli a besoin de la position GPS du téléphone, il faut bien que l'OS le permette. Cette application fait ensuite ce qu'elle veut de cette position GPS et malheureusement ici, elle en fait une utilisation malveillante. Mais encore une fois, ça n'a rien à voir avec les conditions d'utilisation de Google.
[^] # Re: Ceci n'est pas agressif
Posté par chmduquesne . En réponse à la dépêche La Quadrature du Net a besoin de soutien pour boucler son budget 2013. Évalué à 7.
Le plus bizarre pour moi, est que jusqu'à récemment la QdN n'était même pas une association loi 1901. Apparemment ça a changé récemment.
Concrètement ça m'avait toujours gêné que des mecs réclament de l'argent sans qu'il n'y ait d'association derrière. Ça voulait dire pas d'obligation d'avoir un trésorier, et donc personne officiellement responsable de tenir les comptes… On mettait tout simplement son argent dans une boîte noire.
Maintenant que ça n'est plus le cas, on peut peut-être demander à voir leur budget et leurs comptes?
[^] # Re: Ma technique avec apache
Posté par chmduquesne . En réponse à la dépêche sslh 1.10, la bête noire des censeurs. Évalué à 3.
C'est clairement une meilleure méthode. Une boîte munie d'un pare-feu correct va très facilement détecter les paquets ssh et les filtrer. Je le sais car j'en ai déjà fait les frais: ssh, ça se voit, même sur le port 443.
En faisant du ssh sur ssl, le flux passe pour une connection ssl anodine (ce qu'il est, d'ailleurs) et on risque beaucoup moins de se faire prendre. À priori, pour contrer cela, il faudrait être capable de reconnaître l'utilisation du CONNECT, mais comme ce CONNECT se fait seulement après établissement de la connection SSL, je doute que cela soit possible facilement.
Au vu des liens que tu donnes, j'imagine qu'il mérite d'être signalé qu'il existe au moins une méthode permettant de se passer de patcher apache: passer par stunnel. J'en ai fait un petit article (en anglais) 1.
[^] # Re: Organisation
Posté par chmduquesne . En réponse à la dépêche Apéro Ruby à Sophia-Antipolis le mardi 6 septembre 2011. Évalué à 1.
Dommage que je ne sois pas dans le coin, j'y aurais bien fait un tour :)
[^] # Re: Google-opérateurs-utilisateurs
Posté par chmduquesne . En réponse au journal Android et virus. Évalué à 3.
Toi, tu voudrais imposer en plus des catégories dont les droits sont restreints par défaut. À première vue, ça limite aussi: Pour reprendre ton exemple, si je fais un jeu multi-joueur basé sur un échange de sms, j'ai plus le droit de le classer dans la catégorie "jeux", c'est dommage. Mais l'idée me plait, je me permet de la décliner: une possibilité serait que Google ajoute une propriété obligatoire dans le Manifest.xml (genre applicationType) et que le processus d'installation notifie l'utilisateur si une application d'une certaine catégorie utilise des permissions suspectes, avec un pop-up du style: "Cette application utilise des permissions peu habituelles pour sa catégorie. Il vous est recommandé d'être vigilant à son égard. Annuler/Continuer".
[^] # Re: Google-opérateurs-utilisateurs
Posté par chmduquesne . En réponse au journal Android et virus. Évalué à 4.
Celle-ci permet de contrôler son téléphone via jabber: tu en fais un de tes contacts (tu lui crées un compte au préalable) et tu peux, en discutant avec, le commander à distance (envoi/récupération de sms, position gps, état de la batterie etc...). C'est super utile de pouvoir agir à distance sur le téléphone, mais quand tu réfléchis cette appli agit de la même manière qu'un troyen. Quelques modifications suffiraient à la camoufler pour donner un accès presque total et invisible au téléphone à quelqu'un de malveillant. Dans la même veine, l'accès à la carte SIM et au hardware ID peuvent être utile si on vole le téléphone (par exemple HTC permet sur son site de rendre inutilisables les téléphones déclarés volés, je pense qu'il est possible qu'ils utilisent cela).
Que veux-tu faire vis à vis de cela? Si tu empêches de le faire, mon application n'existe plus. Si au contraire tu le permets, tu ouvres la porte aux programmes malveillants. Google choisit d'ouvrir plus de possibilités. Personnellement je ne m'en plains pas, je préfère plus de liberté même si cela implique plus de risques. Aux utilisateurs de ne pas installer n'importe quoi et aux développeurs de gagner leur confiance.
[^] # Re: Google-opérateurs-utilisateurs
Posté par chmduquesne . En réponse au journal Android et virus. Évalué à 10.
Cette partie de ton commentaire me semble techniquement fausse et lourde de raccourcis. Ayant développé sous Android, je me permet de corriger.
Je vais passer rapidement sur l'affirmation "Google vend les données personnelles des utilisateurs", car je ne dispose pas de preuves de leur honnêteté. D'après leurs conditions générales d'utilisation, s'ils utilisent bien ces données personnelles pour cibler leurs pubs, ils ne sont pas sensés commercialiser ces données.
C'est surtout la deuxième phrase qui me fait tiquer: "Du coup, sur Android ils sont obligés de laisser un accès à ces données à certaines applications". L'article dit: "they transmit information on the device's location, its hardware ID and SIM card back to the remote computer". Le fait que ces informations soient disponibles aux applications n'a rien à voir avec la politique de Google vis à vis des données personnelles, il a plus à voir avec le bon fonctionnement de celles-ci. Si une appli a besoin de la position GPS du téléphone, il faut bien que l'OS le permette. Cette application fait ensuite ce qu'elle veut de cette position GPS et malheureusement ici, elle en fait une utilisation malveillante. Mais encore une fois, ça n'a rien à voir avec les conditions d'utilisation de Google.