Potrebbe essere sociale e/o culturale e cerco di condividere i miei pensieri - senza giudicare nessuno - proprio per questo.
Alcune persone vivono in paesi che sono resistenti ai cambiamenti e completamente censurati (quindi potrebbero normalizzare cose che attaccano direttamente la libertà da diverse prospettive o culture).
Ma Discourse vuole essere la piattaforma forum di punta in tutto il mondo e penso che discutere attorno a questo tipo di argomenti sia sempre una buona cosa per tutti.
Grazie per lo spazio. Spero che possa essere rivisto per non danneggiare i casi d’uso, ma nemmeno la fiducia in Discourse da parte degli utenti e delle comunità
Stiamo parlando di prevenire usi potenzialmente molto dannosi in grandi community e di non compromettere la fiducia che gli utenti accordano a Discourse.
Non stiamo parlando di forum ciechi o di impedire agli amministratori di avere i dati perché ciò è impossibile dalla base centralizzata che utilizza un singolo database.
Penso che questa domanda rientri perfettamente nel dibattito “SÌ ma” e non in quello “SÌ o NO”.
Mi dispiace, ma non è questo il punto del mio argomento. Puoi aprirne un altro e chiedere quello che vuoi.
Rimuovere l’impersonificazione non previene questo, è altrettanto facile anche senza. L’effetto primario della rimozione dell’impersonificazione sarebbe rendere più difficile la risoluzione di problemi specifici dell’account.
Dovresti avviare una demo e provare alcune delle funzionalità di amministrazione, non hai bisogno di accedere al database o impersonare qualcuno per cambiare le parole di qualcuno o leggere i loro messaggi.
Se è un clic o una dozzina di clic, fa poca differenza, è comunque possibile. Conosco qualcuno che lavora da casa frequentemente e deve passare attraverso circa mezza dozzina di password, ID a due fattori e altre procedure per accedere ai sistemi interni della sua azienda, ma gli ci vogliono solo pochi minuti.
O tu e i tuoi utenti vi fidate degli sviluppatori e degli amministratori, o non vi fidate. E se non vi fidate del sistema, allora il modo in cui lo utilizzate probabilmente cambierà.
Dal mio punto di vista, ciò probabilmente convalida che Discourse tiene conto della privacy e della libertà.
Gestire manualmente un database va bene per uno sviluppatore. Un singolo pulsante per ogni amministratore per impersonare è non necessario e non va bene.
Nel mezzo, ci può essere un sistema semplice che mostra in modo trasparente che è stato utilizzato impersonate o qualcosa di simile.
Voglio dire, puoi pensare a delle opzioni o ridurre l’intera cosa alla tua prospettiva.
Devi tornare indietro e leggere i miei ultimi post prima di rispondere di nuovo, gli amministratori possono ancora fare tutto questo senza impersonare o accedere al database. L’impersonificazione e la maggior parte delle azioni amministrative sono già registrate nel caso in cui un altro amministratore abbia bisogno di una traccia per trovare un amministratore dannoso.
Oppure chiudi semplicemente quella funzione aperta con il plugin Encrypt. Alla fine, avere opzioni sulle funzioni che le persone potrebbero trovare problematiche è una buona cosa. Falso senso di sicurezza, protezione, ecc. L’unico sistema sicuro per citare Adama è un terminale offline non collegato ad altri sistemi.
Tutti i pro e i contro hanno un punto di vista valido. Il compromesso è la migliore soluzione per tutte le parti. Immagino che il plugin Encrypt sia stato sviluppato per soddisfare il desiderio e, in alcuni luoghi, una possibile necessità di avere un livello di privacy per il sottosistema PM/DM.
Forse, se non fosse inserito nel Core come opzione, potrebbe essere un plugin che realizza l’effetto desiderato per quei sistemi, ad esempio, self-hosted che desiderano la tranquillità.
Si potrebbe dire che lo script per creare badge personalizzati non ha bisogno di essere disabilitato poiché solo l’amministratore ha accesso diretto per crearli. Tuttavia, questo deve essere abilitato da Root, a meno che ciò non sia cambiato.
Sono d’accordo, in circostanze ideali le persone dovrebbero essere in grado di fidarsi delle persone in posizioni di responsabilità. Sfortunatamente, la fiducia a volte viene mal riposta e scoperta solo in seguito.
Questa è una misura di prestazione, per garantire che i clienti ospitati in un ambiente condiviso non possano mettere in ginocchio i siti degli altri. Rende possibile distinguere tra l’amministratore del server e l’amministratore del forum.
Fare clic una volta o una dozzina di volte sembra simile ma non è la stessa cosa e per questo motivo molte aziende perdono molti soldi per non aver abilitato un semplice pulsante che dice “Annulla iscrizione”.
Probabilmente stiamo parlando del contrario ma dal punto di vista morale ed etico.
Uso Discourse come amministratore da 4 anni e so di cosa stai parlando (casi totalmente diversi dall’impersonificazione degli utenti).
Quello che hai detto non abilita la possibilità di pubblicare come un altro con un singolo clic. È come usare un IP o un ID di terze parti ed è diverso dall’editare i loro post per la moderazione.
A proposito, spero che la crittografia si fermi e rompa la possibilità di leggere i messaggi privati degli utenti, ma questo è per un altro thread e sto aspettando aggiornamenti per testare
Citerò di nuovo questo perché sembra che tu abbia aggiunto la modalità lenta…
Ho giocato con l’idea di alcuni esempi pratici di “cambio di proprietà” e/o “modifica il tuo post e nascondi la revisione” per dimostrare che si tratta principalmente di un argomento inutile riguardo al metodo utilizzato per far sembrare che tu abbia detto qualcosa che non hai detto senza toccare il pulsante impersona, ma ho deciso di non farlo.
Ma ci sono certamente più di qualche modo in cui potrei essere un completo stronzo con tutti i pulsanti magici che ho solo nell’interfaccia utente, per non parlare del gioco con la console rails. Penso che molto dipenda dalla fiducia della comunità, non solo dall’amministratore, poiché molte di queste funzionalità sono disponibili anche a livello TL4/catmod/mod. Penso che in generale il gruppo ‘staff’ generalmente non si sforzi di essere distruttivo con nessuno degli strumenti, poiché sarebbe un atto di autodistruzione della propria comunità.
Pertanto, non capisco perché la funzionalità di impersonificazione stessa venga individuata come non etica?
Seriamente, tutti questi commenti che affermano abusi e altre cose non hanno senso per me, non c’è motivo di disabilitare questa particolare funzionalità. Un amministratore può ancora fare tutto come hanno sottolineato altri.
Ma poi, ancora non vuoi ascoltare gli altri e vuoi creare un problema dal nulla. Ancora non capisco quale sia veramente il problema. Perderai i tuoi utenti? O hai paura che il tuo altro amministratore utilizzi questa funzionalità contro di te? Se è così, allora non dovresti nominare amministratori di cui non ti fidi, semplice come questo.
Sarò perfettamente onesto Richard, tu e @merefield avete scenari d’uso positivi molto validi. Ma sento che entrambi vedete solo come la modifica degli elementi con impostazioni opzionali ostacolerebbe i vostri flussi di lavoro. Il che in realtà non farebbe, poiché se state fornendo hosting, la funzionalità non cambierebbe per nessuno di voi.
Salvo, ad esempio, se avessi pubblicato un problema con cui avevo bisogno di aiuto con accordi per un compenso monetario o pro bono. Tu o Robert o chiunque offra aiuto potete delineare gli strumenti necessari da un Discourse self-hosted.
ad es. “Dan posso aiutarti per $X a risolvere il tuo problema. Avrò bisogno di quanto segue. Per creare un account sul tuo sito e concedere l’accesso Admin, avrò anche bisogno di accedere a Impersonate (con un elenco di utenti autorizzati a utilizzare la funzionalità in modo da poter diagnosticare e risolvere il problema in modo corretto ed efficiente. Se hai Impersonate disabilitato dovrai far sì che il tuo admin root lo abiliti. Se accetti i miei termini possiamo iniziare questo processo.”
Lo automatizzerei, quindi non sono affatto preoccupato per questo (infatti, ho uno script di shell che prende il nome host e il nome utente di un’installazione di Discourse ospitata da noi come argomento, e mi fornisce un link di accesso (incluso 2FA e login).
Ho già spiegato le mie obiezioni più di due ore fa (ma le ripeterò volentieri per evitare ulteriore confusione sui miei motivi)
Nel mio miglior tentativo di riassumere manualmente ciò che sto leggendo con GPT-4:
Alcuni desiderano un maggiore attrito per impersonare
Alcuni desiderano l’attuale livello di basso attrito per impersonare
Per coloro che desiderano un po’ più di attrito (io sono in quella schiera, perché personalmente non voglio essere tentato di cliccare sul pulsante, simile a Screen Time e altri trucchi su iOS per aiutarmi a evitare la tentazione):
Aggiungi un componente tematico molto semplice al tuo sito con il seguente CSS:
.btn-impersonate {
display: none;
}
Forse desideri ancora più attrito di così, e magari qualcuno potrebbe creare un plugin o un componente tematico più avanzato per farlo, ma voglio provare questo e vedere se mi fornisce abbastanza attrito per evitare qualsiasi tentazione indesiderata.
Per me, questo è il punto principale. Gli amministratori possono ancora “impersonare” gli utenti con gli altri strumenti disponibili, letteralmente a pochi clic di distanza.
Ma alla fine della giornata, Discourse è un progetto open-source con un sistema di plugin, puoi sempre far funzionare le cose nel modo che ritieni giusto per la tua community.
Se desideri un plugin, inizierei con uno che sovrascrive Guardian.can_impersonate?, è utilizzato dal serializzatore che determina la presenza del pulsante Impersona e dai controlli backend. Almeno da un rapido test sulla mia istanza di sviluppo, ha funzionato:
# plugin.rb
after_initialize do
class ::Guardian
def can_impersonate?(target)
false
end
end
end
