Posts by sutorinfo

  • ADV-Vertrag zusätzlich vorgeschrieben?

    Without IP there would be no internet. Unfortunately exact this address was qualified as a personal date.


    Today we are realizing a lot of threads to websites, hacks from anywhere and with a great portion of professionality. And exact this fact is the reason to log IPs.


    Within the GDPR there is the instrument of the "legitimate interest". In Germany there is so far an agreement on 14 days ( @Nuxwin sources for 7 days? Maybe the discussion in France?).


    Regard: a great publishing company (books on security and law) mentioned in their own declaration of data protection 90 days! They should know! Should be ok, too. Just imagine: if there is a consent on 7 days any attacker would only enlarge his attacking frequency. Just don't forget to mention this logging time exactly.


    After all i would support Nuxwins kind of view. Don't be too strict on the backend. First do your homework on the frontend and - that's really new - document your data processing and data access.


    Additionaly to @fulltilt:
    Immer, wenn ein "Dritter" ins Spiel kommt, sollte ein ADV-Vertrag vorliegen.
    Deinerseits, wenn du Dienstleistungen anderer in Anspruch nimmst.
    Von deinen Kunden, wenn du für sie Daten speicherst oder bearbeitest.
    Es wird zunehmend einfacher, weil auch das Ankreuzen eines Online Formulars ausreicht. Es ist nicht mehr Briefpost oder E-Mail-Verkehr erforderlich.

  • DSGVO & ADV-Vertrag wie macht Ihr das?

    Es liegt im Verantwortungsbereich der Kunden, einen solche Vertrag vorliegen zu haben. Sie müssen ja auch beurteilen, ob du für diese Personenbezogene Daten verarbeitest. Es könnte durchaus passende Konstellationen geben, etwa wenn serverseitig keine pbD mitgeschrieben werden (IPs!!). Ich würde - falls dies dennoch geschieht (der Regelfall) - darauf hinweisen. Nimm Vergleiche anderer Provider aus dem Netz. Alle werden das anbieten. Denkbar ist auch, dass diese drei Kunden nur eigene Daten auf dem Rechner verursachen, etwa hinter einem geschützten Zugang.

  • Group-Office as Webmail for 1.6?

    Hi @fulltilt


    interesting Application and good to have a community version of this opensource solution. In coming version (full rewrite!) it wants to be responsive. Roadmap for 2018 tells us improvements on version 6.x.


    Well, there are a lot of good webbased applications out there. Because its focus on security, privacy and federation I prefer nextcloud with may be far more options and features. But you are talking of an integration into i-mscp. Currently we have rainloop and roundcube as webmail solutions. Both with their advantages, well tested and sufficient as a fallback, if imap for any reasons fails.


    The developers team of i-mscp is very small. So I would be glad, if they can concentrate on the core of i-mscp. Lets have reliable and responsive software here. Or have an upgrade feature from within. Or present more system information. Anything else related to webadministration. Oh, yes, the multiserver thing :-)


    My suggestion for us as a community would be to fill a table telling us s. th. about the compatibility of these versions. Say Group-Office v6.3 is running on i-mscp 1.5.x without problems or some small tweaks or needs certain plugins.


    What do you think?

  • AWStats IP anonymizer

    Some thoughts of mine...


    The upcoming DSGVO (de) GDPR (en) will have implications on any website. And they are complex. Generally, in Germany we had a data protection law quite similar to the GDPR, but most small enterprises were very relaxed... With the new GDPR in most countries the law gets more strict and - more important - enforcement with high fines is intended.


    How are "we" doing now?


    First, GDPR affects as well B2C as B2B. In Germany most important is to fullfill those parts being detectable by robots first. That is the imprint and the declaration of data protection. Check any formula, control your data flows, SSL is mandatory for anyone!! So, the first steps to be taken are those by website owners. Just to mention: GDPR is not only valid for digital data procession, also your paper cards have to follow these paragraphs.


    Next part: Its for sure, that the IP belongs to the personal data. There are a lot others. There are few exemptions. E. g. those data necessary for the website to operate. IPs are such. Questions arise when going into the details. How long should an adress be saved? Can it be pseudnoymized/anonymized, is this allowed? To give you an impression: even soliciters have no common meaning, if saving for some days to allow fail2ban to work is allowed. There is already a great discussion on wordpress comments (but that's no imscp problem). As the whole intention of this law is data minimalism, everyone should ask himself: do I really need this data? For technical reasons (s. a.), for marketing reasons?


    For any data to be processed, you need the admission of the data owner. Another reason is to keep them for legal reasons. According to the law, we are no telecom providers, so we don't have to log access data.


    So, as the necessity for saving/deleting/anonymizing data derives from the client, opting in or out for such things should be implemented on a client level. Imagine there's a client providing a solution only for members having opted in for the logging of their IPs. This is defintively allowed, so this client should be able to log them via AWStats. Maybe a reseller/admin gets a switch for generally disabling this for all clients.


    Resellers: they should have a document signed with the admin called mandatory data processing (in de: Auftragsdatenverarbeitung). Also the clients mostly have to sign such a thing with resellers.


    Further on: Admins/Resellers should be able to answer the question, which personal data could be accessed by whome. By concept, the admin is able to see all client data of any reseller. For transparancy reasons the reseller has to tell this fact to his client or at least document this in his data processing list (in de: Verfahrensverzeichnis).


    Application related aspects: some developers already began to analyse their applications for GDPR-readiness. Even DNS: they discuss, which data should be requested from a domain registrant, which data should be presented for a whois request. We have bind on board. Access to the imscp panel, provided by a webserver: there is a limited number of clients who easily may opt in whereas a blog has outnumbered users, unwilling to have registered their visit.


    What could be a best solution:
    - document, where in imscp personal data are collected
    - who can see/change/delete them
    - which data originate from imscp purposes
    - which data originate from client applications / public website usage / standard server programs
    - which of these data are so open, that the user gets knowledge of them
    - which of these data are given because of technical reasons internally (e. g. apache log, mail log)
    - for which of the personal data is an anonymisation necessary, because there is no legal justification
    - where is there an interaction between imscp and other third party programs; which rules should be obtained in this case
    - ... some more?


    As said above: most important are all the data exposed to the public. Clients in the sense of impsp are public. Imagine a bad willing soliciter (they exist in Germany, because that's a profitable business model) will log in as client on an imscp administered system and is able to see personal data (visitors IPs)! This should be fixed first, even if we have to miss some functionality for some time. Data only visible for admins may be investigated and fixed later.


    In the long run this will be a subject for quite a long time. Heavy stuff? Just wait for E-Privacy next year which goes more into the details.


    Was this long comment helpful to you? Hope so :-)