Not signed in

Want to take part in these discussions? Sign in if you have an account, or apply for one below

• Username
• Password
• Remember me

• Sign in using OpenID
• Remember me

• Forgot your password?
• Apply for membership

2-category 2-category-theory abelian-categories adjoint algebra algebraic algebraic-geometry algebraic-topology analysis analytic-geometry arithmetic arithmetic-geometry book bundles calculus categorical categories category category-theory chern-weil-theory cohesion cohesive-homotopy-type-theory cohomology colimits combinatorics complex complex-geometry computable-mathematics computer-science constructive cosmology deformation-theory descent diagrams differential differential-cohomology differential-equations differential-geometry digraphs duality elliptic-cohomology enriched fibration foundation foundations functional-analysis functor gauge-theory gebra geometric-quantization geometry graph graphs gravity grothendieck group group-theory harmonic-analysis higher higher-algebra higher-category-theory higher-differential-geometry higher-geometry higher-lie-theory higher-topos-theory homological homological-algebra homotopy homotopy-theory homotopy-type-theory index-theory integration integration-theory k-theory lie-theory limits linear linear-algebra locale localization logic mathematics measure-theory modal modal-logic model model-category-theory monad monads monoidal monoidal-category-theory morphism motives motivic-cohomology nforum nlab noncommutative noncommutative-geometry number-theory of operads operator operator-algebra order-theory pages pasting philosophy physics pro-object probability probability-theory quantization quantum quantum-field quantum-field-theory quantum-mechanics quantum-physics quantum-theory question representation representation-theory riemannian-geometry scheme schemes set set-theory sheaf sheaves simplicial space spin-geometry stable-homotopy-theory stack string string-theory superalgebra supergeometry svg symplectic-geometry synthetic-differential-geometry terminology theory topology topos topos-theory tqft type type-theory universal variational-calculus

1. • CommentRowNumber1.
   • CommentAuthorTobyBartels
   • CommentTimeAug 8th 2012
   • (edited Oct 23rd 2012)
   • PermaLink
   Author: TobyBartels
   Format: MarkdownIn light of increasing spam with forged signatures, I want to formally propose that we equip the nLab with registered password-protected editor accounts. This requires that we talk to Jacques about modifying Instiki. So first we need to decide how we want him to modify it. Here are my suggestions: 1. Turning on these accounts should be an option to Instiki, off by default. But we'll turn it on, at least for the main web. 2. The account consists of a signature (as already used to sign edits to articles) and a password. Different accounts cannot have different signatures. Some signatures will be registered with a password, while the vast majority of possible signatures will remain unregistered. 3. Nobody needs an account to edit. Just edit, and either sign as AnymousCoward (the default) or sign with an unregistered signature, and it should work as before. 4. The default signature AnonymousCoward cannot be registered. 5. Using the administrator password, one can change passwords and delete accounts, in case of lost passwords or hijacked names. Here are some more suggestions that I think that Jacques should be freer to change if it helps with the programming: 1. Each web can decide for itself whether to use accounts, and accounts across different webs are different. 2. When saving edits, the line "Submit as ___ | Cancel (unlocks page)" becomes "Submit as ___ with password ___ (if needed) | Cancel (unlocks page)". 3. If somebody submits an edit using an unregistered signature and something in the password field, then register that signature with that password. Put a note to this effect at the top of the submitted page (where redirect notices go). 4. If somebody submits an edit using a registered signature and nothing or the wrong thing in the password field, then the edit should fail with an appropriate message (where the error from saving an umodified edit goes). 5. The cookie that stores a user's signature can also store their password. I'm trying to keep the interface simple, in line with Instiki's philosophy; but this means that users cannot change their passwords later. These things really don't need to be secure, just something that spammers won't guess.

   In light of increasing spam with forged signatures, I want to formally propose that we equip the nLab with registered password-protected editor accounts. This requires that we talk to Jacques about modifying Instiki. So first we need to decide how we want him to modify it.

   Here are my suggestions:

   1. Turning on these accounts should be an option to Instiki, off by default. But we'll turn it on, at least for the main web.
   2. The account consists of a signature (as already used to sign edits to articles) and a password. Different accounts cannot have different signatures. Some signatures will be registered with a password, while the vast majority of possible signatures will remain unregistered.
   3. Nobody needs an account to edit. Just edit, and either sign as AnymousCoward (the default) or sign with an unregistered signature, and it should work as before.
   4. The default signature AnonymousCoward cannot be registered.
   5. Using the administrator password, one can change passwords and delete accounts, in case of lost passwords or hijacked names.

   Here are some more suggestions that I think that Jacques should be freer to change if it helps with the programming:

   1. Each web can decide for itself whether to use accounts, and accounts across different webs are different.
   2. When saving edits, the line "Submit as ___ | Cancel (unlocks page)" becomes "Submit as ___ with password ___ (if needed) | Cancel (unlocks page)".
   3. If somebody submits an edit using an unregistered signature and something in the password field, then register that signature with that password. Put a note to this effect at the top of the submitted page (where redirect notices go).
   4. If somebody submits an edit using a registered signature and nothing or the wrong thing in the password field, then the edit should fail with an appropriate message (where the error from saving an umodified edit goes).
   5. The cookie that stores a user's signature can also store their password.

   I'm trying to keep the interface simple, in line with Instiki's philosophy; but this means that users cannot change their passwords later. These things really don't need to be secure, just something that spammers won't guess.

2. • CommentRowNumber2.
   • CommentAuthorzskoda
   • CommentTimeAug 8th 2012
   • PermaLink
   Author: zskoda
   Format: MarkdownItexAs this is optional move from the point of view of editors, and has advantages, I am for it.

   As this is optional move from the point of view of editors, and has advantages, I am for it.

3. • CommentRowNumber3.
   • CommentAuthorMike Shulman
   • CommentTimeAug 12th 2012
   • PermaLink
   Author: Mike Shulman
   Format: MarkdownItexI'm all in favor of this. However, I do think that users should be able to change their passwords. I'd also be really unhappy about having to type my password every time I edit, so I think passwords *really* should be stored in cookies.

   I’m all in favor of this. However, I do think that users should be able to change their passwords. I’d also be really unhappy about having to type my password every time I edit, so I think passwords really should be stored in cookies.