Hi Maxim,

I've tested the current state. Seems to be done so far. One little thing I hope... When I choose a purged user I have the possibility (button) to restore that account. Db will be set deleted false... Doesn't make sense, I think.

Purge themselves is a way to disagree (I didn't see it till now...), I think. But a few more clicks are needed to get to that point... But I think this is ok as long as nobody complain about it. This function need to be described in the privacy policy. I hope thats it...

Almost all done? Maybe someone else could also test this.

Do you mean the a sample privacy policy here? /"And maybe you can provide sample "personal data agreement" text?"/

I think at least for english... This is a task for a native speaker... In UK they also need to be compliant with GDPR. Maybe someone from there could provide some text.

Greetings Peter

Am 26.04.2018 um 12:04 schrieb Maxim Solodovnik:
As per current implementation users can purge themselves
This can't be undone ....

Is this "a way to disagree" ?

On Thu, Apr 26, 2018 at 2:35 PM, Peter Dähn <[email protected] <mailto:[email protected]>> wrote:

    Hi Maxim,

    I will test it during the day....

    Yes you are right... This need to be done during registration.
    checkbox and link to the privacy policy that need to be placed
    somewhere.

    Agreement for data processing need to be double opt-in. Most
    likely via E-Mail. I think an e-mail template that could be
    changed easily is the most flexible way.

    And there should a way to disagree further data-processing. "The
    way to disagree need to be as easy as the way to agree"... My
    understanding: that would be our "soft delete"... If this is used,
    there should be a way for the user to reactivate this account.
    E.g. check registration e-mail and if it is soft deleted the
    registration confirm e-mail could have the option to reactivate
    the old account or generate a new one

    Back later, when I've tested current build
    Greetings Peter



    Am 26.04.2018 um 08:09 schrieb Maxim Solodovnik:
    All your comments should be addressed in latest build available

    Could you please re-check?

    This question was not answered .....

    Additional question:
    "Registration-Dialog need to have a button/step to agree the data
    processing. And to this belongs a button to disagree."

    I guess user should be able to register only if he/she agree to
    data processing
    Registration should be impossible if user disagree
    So I guess having following controls at registration dialog would
    be sufficient:

    1) "I agree my data will be processed" checkbox
    2) "display agreement" button

    would it be OK?

    On Wed, Apr 25, 2018 at 6:16 PM, Maxim Solodovnik
    <[email protected] <mailto:[email protected]>> wrote:

        These errors seems to be caused by code changes after testing :(
        I'll double-check it

        IP addresses are cleaned up by periodic job.
        Will also add clean by purge
        Thanks for checking!

        WBR, Maxim
        (from mobile, sorry for the typos)

        On Wed, Apr 25, 2018, 17:33 Peter Dähn <[email protected]
        <mailto:[email protected]>> wrote:

            Hi Maxim,

            first test...

            purge confirmation dialogue should be different from
            delete...



            maybe "Do you really want to purge this item? This can't
            be undone!" Something like that...

            After purge I got an 500 internal error page...

            openmeetings.log:

            /ERROR 04-25 12:05:13.708
            o.a.w.DefaultExceptionMapper:170 [nio-5080-exec-3] -
            Unexpected error occurred//
            //java.lang.NullPointerException: zoneId//
            //    at java.util.Objects.requireNonNull(Objects.java:228)//
            //    at java.time.ZoneId.of(ZoneId.java:311)//
            //    at
            
org.apache.openmeetings.util.CalendarHelper.getZoneId(CalendarHelper.java:30)//
            //    at
            
org.apache.openmeetings.util.CalendarHelper.getZoneDateTime(CalendarHelper.java:43)//
            //    at
            
org.apache.openmeetings.util.CalendarHelper.getDate(CalendarHelper.java:47)//
            //    at org.apache.openmeetings.web.co
            
<http://org.apache.openmeetings.web.co>mmon.GeneralUserForm.updateModelObject(GeneralUserForm.java:173)//
            //    at org.apache.openmeetings.web.ad
            
<http://org.apache.openmeetings.web.ad>min.users.UserForm.onModelChanged(UserForm.java:198)//
            //    at org.apache.wicket.Component.mo
            
<http://org.apache.wicket.Component.mo>delChanged(Component.java:2143)//
            //    at org.apache.wicket.Component.se
            
<http://org.apache.wicket.Component.se>tDefaultModelObject(Component.java:3026)//
            //    at
            
org.apache.wicket.IGenericComponent.setModelObject(IGenericComponent.java:81)//
            //    at org.apache.openmeetings.web.ad
            
<http://org.apache.openmeetings.web.ad>min.users.UserForm.updateForm(UserForm.java:266)//
            //    at org.apache.openmeetings.web.ad
            
<http://org.apache.openmeetings.web.ad>min.users.UserForm.purgeUser(UserForm.java:240)//
            //    at org.apache.openmeetings.web.ad
            
<http://org.apache.openmeetings.web.ad>min.users.UserForm.onPurgeSubmit(UserForm.java:214)//
            //    at org.apache.openmeetings.web.ad
            
<http://org.apache.openmeetings.web.ad>min.AdminBaseForm$1.onPurgeSubmit(AdminBaseForm.java:75)//
            //    at org.apache.openmeetings.web.co
            
<http://org.apache.openmeetings.web.co>mmon.FormActionsPanel$3.onSubmit(FormActionsPanel.java:93)//
            //    at org.apache.openmeetings.web.co
            
<http://org.apache.openmeetings.web.co>mmon.ConfirmableAjaxBorder.lambda$new$5f39bb3f$1(ConfirmableAjaxBorder.java:74)//
            //    at org.apache.openmeetings.web.co
            
<http://org.apache.openmeetings.web.co>mmon.ConfirmableAjaxBorder$ConfirmableBorderDialog.onSubmit(ConfirmableAjaxBorder.java:196)//
            //    at
            
com.googlecode.wicket.jquery.ui.widget.dialog.AbstractFormDialog$DialogFormSubmitter.onSubmit(AbstractFormDialog.java:294)//
            //    at
            
org.apache.wicket.markup.html.form.Form.delegateSubmit(Form.java:1268)//
            //    at
            org.apache.wicket.markup.html.form.Form.process(Form.java:963)//
            //    at
            
org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:787)//
            //    at
            
com.googlecode.wicket.jquery.ui.widget.dialog.AbstractFormDialog.internalOnClick(AbstractFormDialog.java:215)//
            //    at
            
com.googlecode.wicket.jquery.ui.widget.dialog.AbstractDialog$1.onClick(AbstractDialog.java:413)//
            //    at
            
com.googlecode.wicket.jquery.ui.widget.dialog.DialogBehavior.onAjax(DialogBehavior.java:188)//
            //    at
            com.googlecode.wicket.jquery.core.ajax.JQueryAjaxBehavior.re
            
<http://ore.ajax.JQueryAjaxBehavior.re>spond(JQueryAjaxBehavior.java:173)//
            //    at
            
org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.onRequest(AbstractDefaultAjaxBehavior.java:598)//
            //    at
            
org.apache.wicket.core.request.handler.ListenerRequestHandler.internalInvoke(ListenerRequestHandler.java:306)//
            //    at
            
org.apache.wicket.core.request.handler.ListenerRequestHandler.invoke(ListenerRequestHandler.java:280)//
            //    at
            
org.apache.wicket.core.request.handler.ListenerRequestHandler.invokeListener(ListenerRequestHandler.java:222)//
            //    at
            
org.apache.wicket.core.request.handler.ListenerRequestHandler.respond(ListenerRequestHandler.java:208)//
            //    at
            
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:912)//
            //    at
            
org.apache.wicket.request.RequestHandlerExecutor.execute(RequestHandlerExecutor.java:65)//
            //    at
            
org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:283)//
            //    at
            
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:253)//
            //    at
            
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:221)//
            //    at org.apache.wicket.protocol.ws
            
<http://org.apache.wicket.protocol.ws>.AbstractUpgradeFilter.processRequestCycle(AbstractUpgradeFilter.java:70)//
            //    at
            
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:204)//
            //    at
            
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:286)//
            //    at
            
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)//
            //    at
            
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)//
            //    at
            
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199)//
            //    at
            
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)//
            //    at
            
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:611)//
            //    at
            
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)//
            //    at
            
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)//
            //    at
            
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:651)//
            //    at
            
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)//
            //    at
            
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)//
            //    at
            
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:407)//
            //    at
            
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)//
            //    at
            
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:754)//
            //    at org.apache.tomcat.util.net
            
<http://org.apache.tomcat.util.net>.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1376)//
            //    at org.apache.tomcat.util.net
            
<http://org.apache.tomcat.util.net>.SocketProcessorBase.run(SocketProcessorBase.java:49)//
            //    at
            
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)//
            //    at
            
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)//
            //    at
            
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)//
            //    at java.lang.Thread.run(Thread.java:745)/

            this error is also shown after choosing a purged user.
            Set time_zone manually in db fixed it.
            time_zone seems to be deleted while purging and then it
            causes the error.

            om_user-table will be handled correctly.
            conference_log preserves the ip-address
            address-table preserves the address
            chat-table preserves  from_name

            Did I miss something?


            Am 25.04.2018 um 09:00 schrieb Peter Dähn:
            Good morning Maxim,

            I was alone in the office these days... unfortunatly
            there were no time left... But I red right in the moment
            the RUNNING.txt... all a bit different... ;-)

            I'm going to text it now... give me a bit time... ;-)

            Am 25.04.2018 um 04:41 schrieb Maxim Solodovnik:
            Good morning Peter :)

            were you able to take a look at this issue?

            On Mon, Apr 23, 2018 at 2:37 PM, Peter Dähn
            <[email protected]> <mailto:[email protected]> wrote:
            Hi Maxim,

            I will have a look right now.

            Greetings Peter


            Am 21.04.2018 um 18:17 schrieb Maxim Solodovnik:
            Hello Peter,

            this is partially implemented
            Could you please test current implementation using
            latest nightly build?

            And maybe you can provide sample "personal data
            agreement" text?

            On Wed, Apr 11, 2018 at 6:38 PM, Peter Dähn
            <[email protected]> <mailto:[email protected]> wrote:
            I try... ;-)


            Am 11.04.2018 um 13:11 schrieb Maxim Solodovnik:

            Will write it as a requirement, will see what can be
            done here
            Thanks a lot for the quick answers!

            On Wed, Apr 11, 2018 at 5:34 PM, Peter Dähn
            <[email protected]> <mailto:[email protected]> wrote:
            ip-address is now a private date... it have to be
            at least anonymised
            after 7 (maybe 14 days)... ipv4 addresses delete
            last 8 recommended 16
            bit
            (192.168.123.0 or 192.168.0.0) and ipv6 preserve
            first 48 -8 or better
            16
            Bit (2a00:1234:56:: or 2a00:1234::) Maybe this
            could be done automated
            after
            7 Days?

            Greetings Peter

            Am 11.04.2018 um 09:31 schrieb Maxim Solodovnik:

            According "Hash algorithm" I planned to use random
            UUID
            so All fields will look like this:
            "Purged_54cd4426-1c0a-4ab8-bb35-eb6d26da99cf"

            Are you sure IP should be cleaned-up? There will be
            no chance to
            "restore"
            who was this user .....

            On Wed, Apr 11, 2018 at 2:18 PM, Peter Dähn
            <[email protected]> <mailto:[email protected]> wrote:
            Hi Maxim,

            I think this list is complete and you are right,
            this is a lot of
            stuff.

            The option that you suggest sound much more
            feasible. From my point of
            few this should be enough.

            Hash algorithm need to be state of the art.
            IP-address in ConferenceLog
            need to be cleaned.

            I think this is a good way.

            Btw... is there is a way/setting to anonymize
            IP-adresses while
            logging?
            Otherwise I need to write a script to do so. Maybe
            I need to do it
            anyway to
            kick out usernames. Logfiles need to be delete
            after 7 (maybe 14) days
            or
            they need to be without any userdata.

            Greetings Peter


            Am 11.04.2018 um 06:43 schrieb Maxim Solodovnik:

            Hello Peter,

            Here is the high level list of what need to done
            to "hard delete" user
            from the system:

            delete user
            delete all user contacts (also users, so we might
            have recursion here)
            delete user from all groups
            delete user from room moderators
            delete all appointments with owner == user
            delete all calendars with owner == user
            delete all meeting members in appointments where
            owner != user
            delete all Private Messages where user is in
            to/from fields
            delete all UserContact + Requests
            delete all invitation sent by this user
            delete all private rooms owned by this user
            delete all user private files/recordings
            delete all chat messages send/received by this user
            clean email messages
            clean all Polls/answers


            This list scares me a lot :(((

            So let's discuss the option: "Mark user deleted
            and clean-up sensitive
            information"

            What I would propose:

            In Admin->User area

            display all users (deleted should be "read-only"
            with restore and purge
            options only)
            add additional "Purge" button
            In case Purge will be selected:

            User will be marked deleted
            AsteriskSipUser and Address will be replaced with
            empty objects
            User fields "age, externaluserid, firstname,
            lastname, login,
            pictureuri"
            will be replaced with "Purged_some_hash"
            User profile picture will be deleted
            ChatMessage: fromName will be replaced with
            "Purged User"
            MailMessage: should be purged (some search by
            email will be required)

            ConferenceLog right now contains userId+UserIp
            right now, so it is 2
            numbers should it be cleaned up?

            SOAPLogin contains clientURL and doesn't contains
            userId, so it is
            impossible to associate SoapLogin object with
            particular user


            Would it be enough?


            On Fri, Apr 6, 2018 at 4:21 PM, Peter Dähn
            <[email protected]> <mailto:[email protected]> wrote:
            Hi Maxim,

            hard delete as only option would be the easiest
            way (for the admin).
            One
            doesn't need to remind "hard delete" at a given
            time... I think it
            need to
            be implemented anyway. I thought just the ones
            that doesn't need to
            take
            care about these regulation could keep things as
            they are now...

            Greetings Peter


            Am 06.04.2018 um 10:09 schrieb Maxim Solodovnik:
            I'm afraid there will be no option to "final
            delete one record"
            It will be: perform total clean-up and hard
            delete all soft deleted
            records

            Or better to perform: hard delete as the only
            option?

            On Fri, Apr 6, 2018 at 2:44 PM, Peter Dähn
            <[email protected]> <mailto:[email protected]> wrote:
            Hi Maxim,

            "soft" and "final delete" should be enough I
            think...

            It just need to be "findable" and described for
            new admins that
            provide the
            service in the EU...

            jira in a second...

            Greetings Peter


            Am 05.04.2018 um 17:47 schrieb Maxim Solodovnik:
            Hello Peter,

            This sounds like lots of new testing :(
            Will try to find time and include it in
            4.0.3/4.0.4

            (have very limited time right now :( )
            Will appreciated any help with testing

            Would it be OK to perform "final delete" in
            clean-up widget? i.e.
            delete will be "soft delete", then in if will
            push "Clean-up" all
            soft
            deleted data will be hard deleted ...
            Or it doesn't worth to have both? only hard
            delete will be enough?

            On Thu, Apr 5, 2018 at 5:55 PM, Peter Dähn
            <[email protected]> <mailto:[email protected]> wrote:
            Hey there,

            new privacy regulations will take place on
            the 25th May 2018 in
            Europe.
            You
            could find informations about it by searching
            for General Data
            Protection
            Regulation (EU) 2016/679.

            To use openmeetings after the 25th of May (in
            Europe) there need
            to
            be a
            few
            changes. We use openmeetings integrated. So I
            will mainly be
            focused
            on
            the
            room.

            I have 3 points that are really necessary:

            1. User deletion: Datasets of users that will
            be deleted need to
            be
            remove
            from the database, not just marked as
            deleted. Probably it is
            enough
            to
            hash
            those fields.

                    I think critical fields are in table:

            om_user -> age, externaluserid, firstname,
            lastname,
            login,
            pictureuri (and picture itself) and sip_user_id

            conferencelog -> email, external_user_id,
            firstname,
            lastname,
            user_id, userip

            soaplogin -> client_url (contains the
            ip-address)

            sipusers (here empty so please check) ->
            defaultuser,
            host,
            ipaddr, name

            address -> email, fax, phone

            chat -> from_name

            e-mail_queue (if not empty) -> recipients,
            replyto

            2. There need to be a place to place a
            (customized) privacy
            policy.

            3. Registration-Dialog need to have a
            button/step to agree the
            data
            processing. And to this belongs a button to
            disagree.


            As far as I can see this need to be done in
            the first place. I'm
            sure
            there
            are more things to do. Maybe someone can
            complete it.


            Greetings Peter



-- WBR
            Maxim aka solomax



-- WBR
            Maxim aka solomax



-- WBR
            Maxim aka solomax








-- WBR
    Maxim aka solomax




--
WBR
Maxim aka solomax

Reply via email to