-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Privacy enhancements for contacts menu #5107
Comments
Hi. In the JSXC app there are also requests for such restrictions (e.g. jsxc/jsxc#306). For the best UX I think it's very important that the implementation is the same. How should this be implemented in the Chat app?
(Note that this still is important even if the contacts menu and roster will by merged (nextcloud/jsxc.nextcloud#21), because otherwise users could manually start a conversation) |
This is really essential to address. Users should be able to look up and autocomplete users in their groups and their groups ONLY. |
As all group-/autocomplete-related issues are pointing to this issue, I'll add my findings when using 12.0.1 here in relation to the admin-option: "Allow username autocompletion in share dialog. If this is disabled the full username needs to be entered."
Quick update: PR 5107 @ #5585 seems to fix part 2.ii, but not 2.i or either of the issues below 1.. |
@ebogaard, there is another aspect: 1.i and 1.iii should come in separate settings (separate from username autocompletion). Actually, my usecase is not about exposing usernames but email addresses only. I just learned that users can hide their email address from others, but this is not the default. I.e. when an admin creates a user with his email address (to send the welcome message), then this email address is exposed immediately until the user logs in and changes the privacy setting. Shall I open another ticket for this issue? |
Why is this unexpected? As I see it the Contacts menu is meant as the start-point for Collaboration (Sharing, E-mailing, Chatting ... ) and we want the options to limit and control sharing to have the same effects on the other forms of collaboration. I agree the options should be renamed then a bit. See e.g. #4656 (comment) |
Another issue I was facing: shouldn't the |
This is unexpected for two reasons:
If I think of it: if you only look at the contacts menu, the disable autocomplete-option should actually read "Disable contacts menu". |
@schiessle @blizzz @LukasReschke can you look at this? All the cases noted here should be integrated in the existing options. |
Depending on the sharing options. There you can limit it to groups only. I would not restrict it to this by default, since a group structure is not necessary and the default experience would appear broken ("I cannot interact with anyone!"). |
even if you limit share to a group, you can see all contacts |
Will this be backported to NC12 ? Unless this feature is disabled or at least restriced to groups i cannot upgrade to version 12. |
@BornToBeRoot it is not even there in the code yet, that would be the first step. |
I bumped my PR for some love 😜 To all the people in this thread can you please test the PR and see if it has the desired result for you? @BornToBeRoot my PR will be backported to 12 and IMO other improvements should be too. |
what do you mean PR ? personal repo ? pre release ? How can I test ? I'm using stable branch NC12.0.2 but I can upload some code in my test server. |
i agree this option ! |
@MorrisJobke : shloud be implemented into 12.0.3 version ? |
@jimbowarrior 12.0.3 is already released (RC2) Please implement in 12.0.4! So i can finally migrate from 11 to 12 |
Backport at #6554 |
Please see #5606 - someone has referenced that issue and said it is duplicate of this, while it is not. While this share-and-see-users-outside-group bug is solved (I have confirmed it) in todays build, the Contact main link (header menu - present on all pages - see attachment) is still leaking data from other groups. Very important to get that bug solved. For reference is also OwnCloud suggesting years back (google it) that groups is suggested to be used to completely isolate business. It would be strange to do something completely different here. Another thing is that it doesn't do anything (if this is by intent and developer really wants users to search outside your goup). You can search in contact, but when you click them, nothing happens. So it is only a showstopper and no-one has any use to just search usernames? I would just disable this Contact-menu-option in this case (where you have opted to not share outside groups). It will not kill any known functionality. |
maybe there is a problem with the backport to the stable branch? |
@rotanid No, this is a daily build. I activated daily and ran update in hope that it was fixed. But it wasn't (12.0.3 Build:2017-09-27T01:01:16+00:00) |
This is a little to important to wait for next version I think.... |
Hi @ixmann99 I just tested stable12 and can confirm this is solved. But you have to disable this listing of Contacts outside of your groups, To do this:
There are two main uses cases for groups: enable collaboration and to completely isolate business, there is no good default for this IMO.
That's because you don't have an app enabled which uses this feature (Email, chat etc). |
Hi @LEDfan Number 4. is already checked in my installs. This is so important to me that I have both tested v12 in Softaculous one-click-install and through full blown mysql-install/setup on two dedicated boxes (Centos). The contact menu (with no-clickable names and groups outside your group) still appear unless you ment to say you have re-packed v 12 stable the last days with the fix. If that is the case, I haven't tested it yet. Number 5. destroys crucial functionality so that no users can share anything - not even with their own group. Hardly a solution or even a workaround. See picture below, demonstrates that 4. still is showing and that 5. is destroying the share-function both for groups and people in same group. BTW: The users displayed in the Contact-menu belongs to other groups, not the current user I'm logged in as/belong to. |
Hello: I just realised today that any user on my server can see the name and email address of any other user! Wow, that is a major problem for me. I use my server to share files with clients and it is not appropriate for clients to see a list of my other clients --- AND THEIR EMAIL ADDRESSES! I'm not sure when this started, NC12 I guess. I'm on 12.0.3 (I think) and I have the Contacts app disabled. Is there a fix coming for this? Did I miss a setting somewhere that will stop it? Can I modify a file to fix it? At present it seems the only solution is to assign fake names to everyone and delete the email addresses! |
The contacts menu is not part of the Contacts app. ;-) |
You can manage in the settings (admin) to hide ALL the contacts. But every time that you want to share a link, you have to type the exact user name. Also ThomasMarx suggested to hide the dangerous menu with CSS : |
The App Circles does not honour "Allow username autocomplementation in share dialog ..." setting! If Circles enabled and you add a new circle and you click on add a member it will propose usernames to you. |
@xshadow please open a bug at the circles app https://github.com/nextcloud/circles |
I already did: nextcloud/circles#152 :) |
same issue !!! |
Did you uncheck the option, in tab sharing?: "Allow username autocompletion in share dialog. If this is disabled the full username needs to be entered." |
If I disable the option, I think it works correctly. But it should work even if the option is enabled... |
Please open a new issue. I lock conversations here, because the original issue is dealt with. Any new issue needs a new report. |
Just mentioning #7428 as the follow-up from @BornToBeRoot |
Follow up of #4656:
possibility to disable contacts menu from
config.php
? 🤔If username-autocompletion is disabled, the contacts-menu should never ever show local users:
We may also want to overthink the federation lookup-settings, since they could be also used for contacts-menu on user-side: 🤔 @schiessle
@ChristophWurst
The text was updated successfully, but these errors were encountered: