jack84an a écrit :je n'ai pas trouvé comment vous envoyer mon fichier comptes sans vous fournir mes numéros de comptes, cartes bleues et leur codes d'accès aux fichiers ofx sur internet. Ce n'est pas que je n'aie pas confiance à priori, mais bon sur le principe ce n'est pas très sûr, non?
Vous avez raison de vous en inquiéter mais par contre les codes d'accès ne sont pas stockés dans le fichier, ils sont dans le trousseau sécurisé du système. Donc je ne recevrais que les numéros de comptes et cartes bleues.
jack84an a écrit :A mon sens il manque une couche de cryptage, non?
La couche de cryptage est fournie par le trousseau système mais pour les codes d'accès uniquement.
jack84an a écrit :d'ailleurs le cryptage a disparu entre V4 et V5 et est remplacé par un "mot de passe software" (j'y reviendrais dans un autre fil plus tard).
Oui car il n'est pas possible de faire du cryptage avec le composant base de données du système, "Core Data".
d'accord, c'est plus rassurant.
En revanche je ne suis pas totalement convaincu par le partage en clair des numéros de comptes et cartes bleues. Ils ont une valeur certaine pour certains hackers qui les utilisent / revendent: est-ce que numéros de comptes et cartes bleues ne pourraient pas être aussi gérés par le trousseau? (je ne sais pas si ma question fait sens techniquement, mais bon)
A défaut est-ce que vous pouvez garantir un niveau de service, i.e. destruction immédiate de mon fichier sur votre mac/mail après résolution du bug ou équivalent? rien n'est dit à ce sujet, et si votre propre mac était hacké / volé les conséquences seraient pour moi...
Evidemment on souhaite que tout cela n'arrive pas mais il faut prévoir le pire.
merci
jack84an a écrit :En revanche je ne suis pas totalement convaincu par le partage en clair des numéros de comptes et cartes bleues. Ils ont une valeur certaine pour certains hackers qui les utilisent / revendent: est-ce que numéros de comptes et cartes bleues ne pourraient pas être aussi gérés par le trousseau? (je ne sais pas si ma question fait sens techniquement, mais bon)
Honnêtement je ne vois pas comment on peut se servir juste d'un numéro de compte ou d'un numéro de CB sans les 3 chiffres derrière mais il est vrai que les hackers ne manquent pas d'idées
jack84an a écrit :A défaut est-ce que vous pouvez garantir un niveau de service, i.e. destruction immédiate de mon fichier sur votre mac/mail après résolution du bug ou équivalent?
Oui ça je vous le garantis, je ne le précise pas en effet mais c'est une évidence pour moi.
L'histoire était assez bizarre mais la suite l'est encore plus:
ma base fait 73 Mo donc j'ai cherché à la réduire en détruisant tous les rapports, catégories, comptes sauf 1 compte avec une opération pour que çà passe par mail, mais j'arrivais à 15 Mo minimum même en faisant des duplications pour enlever l'historique. Existe-t-il un moyen de purger tout en gardant un historique complet?
Bref en visualisant la dernière configuration d'importation je me rends compte que le mot de passe a disparu, je le remets , et çà marche, youpi.
Je détruits alors tous les doubles de bases de données créés par duplication pour diminuer la taille et je relance ma base initiale en me disant que je vais simplement réactiver les mots de passe dans les config d'import. Manque de bol en entrant dans ma vraie base iCompta lui applique la destruction de tous les rapports, catégories, comptes sauf 1 compte avec une opération .. très flippant car le nom des fichiers ou j'ai fait cela était différent . Donc tout se passe comme s'il gardait "en mémoire" des opérations et les appliquait à nouveau... sur un autre fichier source de la duplication. Bug , non?
J'ai remonté 2 fois de time machine la version de la veille en sautant sur la synchro iCloud en me disant qu'il répliquait des modifications vérolées revenant du cloud mais çà n'a pas eu l'air de marcher : la roue dentée iOS tournait, puis finalement après m'avoir enlevé toutes mes opérations (des milliers, gulps), elles sont toutes revenues quand la roue a cesser de tourner. J'ai pu re-checker la synchro iCloud ensuite et tout semble stable maintenant. De ce point de vue on peut dire que la base de données est robuste, mais faut pas me faire des frayeurs comme çà...
Bilan des courses hormis cet "accrochage en mémoire" j'ai maintenant de nouveau ma base et les opérations se telechargent automatiquement à nouveau simplement en réactivant le password dans l'import automatique. Je ne m'explique pas ce qui a pu faire sauter d'un seul coup le password de toutes les configurations d'import simultanément. Bug, non?
J'ai détaillé çà peut toujours donner des idées si d'autres on le même problème et au développer pour corriger. voilà.
PS: quid du trousseau pour les identifiants de compte & carte bleue justement?
jack84an a écrit :L'histoire était assez bizarre mais la suite l'est encore plus:
ma base fait 73 Mo donc j'ai cherché à la réduire en détruisant tous les rapports, catégories, comptes sauf 1 compte avec une opération pour que çà passe par mail, mais j'arrivais à 15 Mo minimum même en faisant des duplications pour enlever l'historique. Existe-t-il un moyen de purger tout en gardant un historique complet?
Bref en visualisant la dernière configuration d'importation je me rends compte que le mot de passe a disparu, je le remets , et çà marche, youpi.
Je détruits alors tous les doubles de bases de données créés par duplication pour diminuer la taille et je relance ma base initiale en me disant que je vais simplement réactiver les mots de passe dans les config d'import. Manque de bol en entrant dans ma vraie base iCompta lui applique la destruction de tous les rapports, catégories, comptes sauf 1 compte avec une opération .. très flippant car le nom des fichiers ou j'ai fait cela était différent . Donc tout se passe comme s'il gardait "en mémoire" des opérations et les appliquait à nouveau... sur un autre fichier source de la duplication. Bug , non?
J'ai remonté 2 fois de time machine la version de la veille en sautant sur la synchro iCloud en me disant qu'il répliquait des modifications vérolées revenant du cloud mais çà n'a pas eu l'air de marcher : la roue dentée iOS tournait, puis finalement après m'avoir enlevé toutes mes opérations (des milliers, gulps), elles sont toutes revenues quand la roue a cesser de tourner. J'ai pu re-checker la synchro iCloud ensuite et tout semble stable maintenant. De ce point de vue on peut dire que la base de données est robuste, mais faut pas me faire des frayeurs comme çà...
Bilan des courses hormis cet "accrochage en mémoire" j'ai maintenant de nouveau ma base et les opérations se telechargent automatiquement à nouveau simplement en réactivant le password dans l'import automatique. Je ne m'explique pas ce qui a pu faire sauter d'un seul coup le password de toutes les configurations d'import simultanément. Bug, non?
Vous avez dupliqué votre fichier dans le Finder donc pour iCompta la copie et l'original sont un seul et même document en ce qui concerne la synchronisation. Donc si vous avez sauvé (Pomme + S ou Fichier > Enregistrer) avec la copie ça a eu pour effet d'envoyer tous ces changements sur iCloud. Quand vous avez ensuite réouvert l'orignal il a vu qu'il y avait des changements récents et à voulu les appliquer, ça a donc tout supprimé.
jack84an a écrit :PS: quid du trousseau pour les identifiants de compte & carte bleue justement?
Ce n'est pas inenvisageable, je verrai peut-être plus tard.
en fait j'avais effectivement copié en finder puis comme çà ne marchait pas j'avais ensuite fait plein de duplications à l'intérieur de iCompta. Donc çà revient au même. Tout s'explique, merci
