Questo è un argomento affascinante, che sembra derivare principalmente da malintesi.
Tuttavia, questo non è un problema di Discourse, questo problema permea qualsiasi sistema online in cui non vi sia crittografia end-to-end e firme digitali / convalida sui messaggi. Discourse non ha nessuna di queste cose out-of-the-box.
In realtà non stai nemmeno discutendo qui, né questo si collega realmente a decisioni prese da Discourse come prodotto o da CDCK come team. Ci sono un sacco di fraintendimenti là fuori, stai solo imparando che il software non può controllare il livello di autorità ultimo su un sistema, cosa che molti di noi sanno in varia misura da decenni.
La reputazione di una community non dipende dalle funzionalità di Discourse, ma dipende quasi interamente da a chi si consegnano le chiavi. Se un amministratore malintenzionato fa qualcosa che scatena l’indignazione della community, a nessuno importerà quanto sia stato facile per loro compiere tali atti perché, in definitiva, sei stato tu e non un particolare pulsante ad averli autorizzati a farlo.
Sembra più che le persone siano diventate ignare del potere che ha l’admin. L’impersonificazione è solo la punta dell’iceberg.
Apprezzo il modo in cui hai inquadrato la questione, perché sì, per me, sono rimasto piuttosto scioccato (e spesso piuttosto spaventato) nello scoprire quanto potere ho come amministratore.
Il motivo per cui ho spesso desiderato la crittografia end-to-end è proprio questo: ridurre il potere che ho come amministratore e ridurre la paura di ciò che potrebbe accadere con quel potere (ad esempio, la capacità di leggere/modificare messaggi, la responsabilità legale di dover segnalare ciò che le persone dicono nelle conversazioni private, ecc.)
Tuttavia, questi non sono problemi che il software libero e open source può risolvere facilmente, nemmeno quello che esiste da un decennio.
A un certo punto, tutto si riduce a un equilibrio tra rischio e fiducia tra le applicazioni che compongono il tuo servizio e le persone che detengono le chiavi di detto regno.
Essere consapevoli del livello di accesso che si ha è in realtà un buon primo passo.
Hai esperienza con l’enorme quantità di ingegneria necessaria per far apparire queste cose semplici e facili da usare?
Abbastanza da sapere che ho un enorme rispetto per gli ingegneri di Signal e molta paura di creare la mia crittografia Ho creato un’app di journaling crittografata nel 2012/13 e quello era un utente che parlava con se stesso su un solo dispositivo… ed è stato comunque un problema, probabilmente non molto facile da usare, e non sono sicuro di quanto fosse sicuro.
Quindi, sì, sono d’accordo, la tecnologia di comunicazione multiutente semplice, facile da usare e sicura può essere straordinariamente difficile da creare e mantenere. Forse è per questo che sono rimasto piacevolmente sorpreso che esistesse il plugin Discourse Encrypt.
Indipendentemente da ciò, i tuoi commenti mi ricordano che sì, questa piattaforma è gratuita e open-source, il che significa che se il team principale decide di non fare qualcosa (ad esempio, crittografia della chat o divieto di impersonificazione) per qualsiasi motivo, sono libero di creare un plugin da solo o pagare qualcuno per crearlo—e quella libertà di farlo se voglio è una delle cose che amo così tanto di Discourse.
IMHO anche i moderatori hanno molto potere in Discourse, ma provengo da un ambiente phpbb3 in cui i moderatori avevano poteri molto inferiori. (Ho anche gestito un sito Mailman per oltre 20 anni, che sto migrando a Discourse non appena riuscirò a capire come spostare 20 anni di messaggi su Discourse.)
Sono stato l’unico amministratore di sistema di quel sito phpbb3 per oltre 15 anni, anche se sono andato in pensione diversi anni fa; non vedo l’ora che quella piattaforma passi a Discourse perché presumo che qualcun altro sarà l’amministratore e non voglio nemmeno essere un moderatore lì, solo un partecipante. Ho consigliato il project leader sui problemi di amministrazione del forum che abbiamo affrontato nel corso degli anni, alcuni dei quali potrebbero influire sulle impostazioni che sceglie di utilizzare, altri potrebbero influire sulle policy che l’organizzazione adotta per gli utenti e per lo staff.
Detto questo, avere restrizioni su chi può usare il pulsante di impersonificazione non mi sembra una cattiva idea, solo una in gran parte simbolica una volta che si è un amministratore esperto. E naturalmente il team di sviluppo o l’amministratore di sistema (su un sistema self-hosted) possono probabilmente fare qualsiasi cosa se si impegnano abbastanza.
L’impersonificazione è uno strumento essenziale e diffuso per gli amministratori. Lavoro nell’hosting web e impersonifico (“Accedi come”) i clienti MOLTISSIMO nel mio pannello di fatturazione. Ci sono abbastanza casi in cui una funzionalità come questa è cruciale, ora in questo caso possono verificarsi i seguenti scenari:
Stai assistendo l’utente e devi vedere cosa sta succedendo dalla sua parte
Stai risolvendo un bug che non si verifica per tutti i tuoi utenti
Devi vedere il frontend dalla prospettiva di un utente
Stai testando l’esperienza utente/flusso
Ora Discourse non è un pannello di fatturazione, ma i casi d’uso sono alquanto simili. Gli amministratori potrebbero dover risolvere un bug o vedere come appare il forum da un gruppo o utente specifico. Di solito impersonifico i miei account alternativi che appartengono a gruppi specifici o hanno uno stato TL/mod/category mod specifico, per vedere come appare tutto dalla loro prospettiva e se non ho perso impostazioni ovvie.
O semplicemente assistendo l’utente con qualsiasi cosa che non sia possibile senza impersonare - non sono sicuro se ci siano impostazioni utente a cui non si può accedere senza impersonare?
Oltre al fatto che qualsiasi amministratore root può già accedere a qualsiasi informazione nel database. Questo è uno dei diritti di accesso che un amministratore ha per natura. La funzionalità di impersonificazione è lì per rendere la vita dell’amministratore più facile, proprio come qualsiasi altra impostazione, sono lì per semplificare le attività amministrative: dall’interfaccia /admin/.
Le uniche impostazioni che so essere un problema credo che tu possa cambiarle come amministratore, ma mostra le tue impostazioni invece delle loro in alcuni punti. Nella scheda Interfaccia, mostra le impostazioni del tuo tema e schema di colori invece di quelle dell’utente, quindi devi impersonarli per essere certo di vedere i valori corretti.
Se sostituisci “Rimuovere il pulsante impersona” con “Rendere il pulsante impersona meno facilmente disponibile”, la frase manterrà il suo significato, non credi?
Volevo solo ricordare:
Potrebbe essere che molte persone abbiano effettivamente dimenticato la possibilità di disabilitare completamente l’impersonificazione dell’amministratore semplicemente installando un piccolo plugin di meno di dieci righe di codice?
Forse penso che la funzione di impersonificazione possa avere un interruttore nelle impostazioni del sito come tutte le altre funzioni, proprio come sussurrare, taggare, pagina utente, registro di accesso ai messaggi privati, ecc.
Se quell’interruttore fosse nelle impostazioni del sito, allora qualsiasi amministratore potrebbe riattivarlo, quindi un clic diventerebbe qualche clic. Non sono sicuro che questo risolva il problema nella mente di coloro che lo considerano un problema. Ma potrebbe renderlo meno una tentazione da usare per curiosare.
Penso che su questo sarebbe fantastico poter configurare quale/i Amministratore/i sul sito tramite riga di comando può accedere a questa funzionalità. Poiché potresti avere Amministratori che necessitano dell’accesso elevato. Sebbene anche la semplice idea di @jimkleiber di utilizzare il CSS per nascondere il pulsante a tutti tranne X+ sarebbe sufficiente per la maggior parte, poiché si tratta solo di rimuovere la tentazione di vederlo. Sebbene il serializzatore del plugin nella stessa idea sarebbe probabilmente migliore, poiché immagina che potresti premere il pulsante invisibile (?)
In effetti, in tal caso, un’opzione da riga di comando di root. Sebbene la maggior parte lo lascerebbe se si trattasse solo di un problema di “tentazione”.
Ecco una PR per un’impostazione globale per disabilitarla. Penso che questa sia la corretta fedeltà. È qualcosa che la persona che installa ed esegue il cluster vuole impostare a livello di cluster.
Ottimo PR! Tuttavia, ritengo che la possibilità di attivare e disattivare l’impersonificazione sia troppo facile con questa nuova funzionalità. Penso che la maggior parte degli utenti si sentirebbe a disagio nel sapere che l’impersonificazione può essere attivata e disattivata a capriccio di un amministratore!
Forse dovremmo considerare un’impostazione aggiuntiva che consenta di attivare o disattivare questa nuova impostazione allow_impersonation. In questo modo non sarò così facilmente tentato di impostare l’impostazione allow_impersonation su “on”. Qualcosa come un’impostazione allow_allow_impersonation. Cosa ne pensi?
Quando supportiamo i clienti, occasionalmente facciamo in modo che un amministratore si impersonifichi in situazioni strane per garantire che il problema non sia correlato al browser/sistema operativo/ad blocker. In quei casi è molto utile e discreto: non pubblicano per loro conto né hanno accesso a nulla che non avrebbero potuto vedere comunque.
Vedo molta confusione tra il tecnico e il sociale. La visione tecnica è che l’impersonificazione è utile e disattivarla non previene abbastanza. La visione sociale è che l’impersonificazione è troppo facile da usare e nella cultura di alcuni forum viola il contratto sociale.
Notare che l’impersonificazione è utile, o addirittura essenziale, non dice nulla sull’utilità sociale o sul messaggio. E così abbiamo persone che parlano tra loro senza capirsi, specialmente forse da coloro che non sono abituati a pensare in termini di aspettative sociali in culture diverse.
Grazie per l’interruttore globale. (Penso ancora che un avviso intermedio sarebbe un miglioramento!)
Oppure dovrebbe essere nella console per consentire questa impostazione. Oppure dovrebbe essere nel codice sorgente per consentirla. O alcuni avvertimenti? Comunque la tentazione è ancora lì cosa fare
Ho creato un’app di journaling crittografata nel 2012/13 e quello era un utente che parlava con se stesso su un solo dispositivo… ed è stato comunque un problema, probabilmente non molto facile da usare, e non sono sicuro di quanto fosse sicuro.
)