Diversification [ branched from Re: conflicts in the gnu project now affect guile]

Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[Todor Kondić]

On Friday, 18 October 2019 17:09, pelzflorian (Florian Pelz) <pelzflorian@pelzflorian.de> wrote:

> On Fri, Oct 18, 2019 at 11:29:35AM +0000, Todor Kondić wrote:
>
> > You know, there is a big IT department within our institution and telling them I will base some serious work on technologies such as GNU Guile and Guix did raise a few eyebrows (those not raised are probably the cause of their proprietors not being informed enough).
> > […]
> > Couple of notes:
> >
> > 1.  Are there any ladies on these lists? I am dying to hear from them
> > 2.  Related to (1) ... a brief look at the maintainers who signed the Joined Statement gives an impression that it leans heavily to the politically Western hemisphere; just a comment, maybe food for thought
> > 3.  The RMS scandal was brought to my attention by a female coder colleague who previously knew nothing of RMS's, or FSF's or GNU's work in the "Open Source Community"; another nibble for thought
>
> There have been few contributions from women,
> e.g. https://lists.gnu.org/archive/html/guile-devel/2017-03/msg00042.html
> (I do not know what its status is), but I believe bringing GNU Guile
> to professional use could help diversify. Thank you for that!
>
> Regards,
> Florian

Hi Florian,

Thanks for the kind words.

The problem of diversification goes way beyond the eccentric, or repugnant (choose at your leasure) views of certain prominent members of our "community".
I've set up my workflows around Guix, git(lab) and a customised Emacs installation (instead of R Studio). My small team of science students (majority female, various cultural backgrounds), never previously exposed to a GNU system to such an extent, managed to get a handle on it quite impressively.

But, I doubt any of them would find it natural to take a step further and participate in GNU itself (ugh, now I sound like a preacher of a new age religion). To my knowledge, interaction within GNU communities is still mostly mailing lists and IRC. This _not_ my students' natural digital habitat. I am probably not saying anything new, though ...

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[John Cowan]

On Sun, Oct 20, 2019 at 2:11 AM Todor Kondić <tk.code@protonmail.com> wrote:

> But, I doubt any of them would find it natural to take a step further and
> participate in GNU itself (ugh, now I sound like a preacher of a new age
> religion). To my knowledge, interaction within GNU communities is still
> mostly mailing lists and IRC. This _not_ my students' natural digital
> habitat.


The only natural digital habitat of human beings is their fingers.  All
else is learned, and more can be learned at any time.  There's no reason
why students ought to be so closed to new experiences.


 John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
Humpty Dump Dublin squeaks through his norse
                Humpty Dump Dublin hath a horrible vorse
But for all his kinks English / And his irismanx brogues
                Humpty Dump Dublin's grandada of all rogues.  --Cousin James

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 974 bytes --]


John Cowan <cowan@ccil.org> writes:

> On Sun, Oct 20, 2019 at 2:11 AM Todor Kondić <tk.code@protonmail.com> wrote:
>
>> But, I doubt any of them would find it natural to take a step further and
>> participate in GNU itself (ugh, now I sound like a preacher of a new age
>> religion). To my knowledge, interaction within GNU communities is still
>> mostly mailing lists and IRC. This _not_ my students' natural digital
>> habitat.

> The only natural digital habitat of human beings is their fingers.  All
> else is learned, and more can be learned at any time.  There's no reason
> why students ought to be so closed to new experiences.

That’s true, but even though I prefer IRC to new protocols, there is
much it lacks. For example showing images inline.

That‘s a client-problem, but it’s real.

Basically this sais that we’re the ones who are closed (often for good
reason, but those reasons need to be explained).

Best wishes,
Arne

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1076 bytes --]

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[Amirouche Boubekki]

Le lun. 21 oct. 2019 à 08:35, Arne Babenhauserheide <arne_bab@web.de> a écrit :
>
>
> John Cowan <cowan@ccil.org> writes:
>
> > On Sun, Oct 20, 2019 at 2:11 AM Todor Kondić <tk.code@protonmail.com> wrote:
> >
> >> But, I doubt any of them would find it natural to take a step further and
> >> participate in GNU itself (ugh, now I sound like a preacher of a new age
> >> religion). To my knowledge, interaction within GNU communities is still
> >> mostly mailing lists and IRC. This _not_ my students' natural digital
> >> habitat.
>
> > The only natural digital habitat of human beings is their fingers.  All
> > else is learned, and more can be learned at any time.  There's no reason
> > why students ought to be so closed to new experiences.
>
> That’s true, but even though I prefer IRC to new protocols, there is
> much it lacks. For example showing images inline.
>
> That‘s a client-problem, but it’s real.
>
> Basically this sais that we’re the ones who are closed (often for good
> reason, but those reasons need to be explained).

They are new client that support IRC like riot.im via matrix

https://about.riot.im/

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[Amirouche Boubekki]

Le dim. 20 oct. 2019 à 08:14, John Cowan <cowan@ccil.org> a écrit :
>
> On Sun, Oct 20, 2019 at 2:11 AM Todor Kondić <tk.code@protonmail.com> wrote:
>
> > But, I doubt any of them would find it natural to take a step further and
> > participate in GNU itself (ugh, now I sound like a preacher of a new age
> > religion). To my knowledge, interaction within GNU communities is still
> > mostly mailing lists and IRC. This _not_ my students' natural digital
> > habitat.
>
>
> The only natural digital habitat of human beings is their fingers.  All
> else is learned, and more can be learned at any time.  There's no reason
> why students ought to be so closed to new experiences.


Regarding the mailling list, many projects (among GNOME) have or will
adopt https://www.discourse.org/. It has a per-user mailling list mode
but it can not bridge mailman. My guess is that a discourse instance
only for GNU Guile and Guix would be overkill, so maybe GNU might
consider using that software?

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[Nala Ginrut]

On Wed, Oct 23, 2019 at 2:17 PM Amirouche Boubekki <
amirouche.boubekki@gmail.com> wrote:

> Regarding the mailling list, many projects (among GNOME) have or will
> adopt https://www.discourse.org/. It has a per-user mailling list mode
> but it can not bridge mailman. My guess is that a discourse instance
> only for GNU Guile and Guix would be overkill, so maybe GNU might
> consider using that software?
>

IIRC there's someone in GNU private mailing-list had mentioned GNOME
discourse, but the later suddenly happened RMS issue had interrupted the
discussion. So that I've no idea where it is now.
Maybe it's a good idea to raise it again.

Best regards.

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[pelzflorian (Florian Pelz)]

On Wed, Oct 23, 2019 at 08:16:34AM +0200, Amirouche Boubekki wrote:
> Regarding the mailling list, many projects (among GNOME) have or will
> adopt https://www.discourse.org/. It has a per-user mailling list mode
> but it can not bridge mailman. My guess is that a discourse instance
> only for GNU Guile and Guix would be overkill, so maybe GNU might
> consider using that software?
> 

I only know that subscribing to GNOME Discourse required Javascript
and its mail headers are less pretty compared to mailman.

I would prefer eventually having a forum/bulletin board-like Web
interface to mailing lists in Guile and until then stick to pure
mailing lists.

Regardds,
Florian

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[Chris Vine]

On Wed, 23 Oct 2019 08:48:13 +0200
"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> wrote:
> On Wed, Oct 23, 2019 at 08:16:34AM +0200, Amirouche Boubekki wrote:
> > Regarding the mailling list, many projects (among GNOME) have or will
> > adopt https://www.discourse.org/. It has a per-user mailling list mode
> > but it can not bridge mailman. My guess is that a discourse instance
> > only for GNU Guile and Guix would be overkill, so maybe GNU might
> > consider using that software?
> 
> I only know that subscribing to GNOME Discourse required Javascript
> and its mail headers are less pretty compared to mailman.
> 
> I would prefer eventually having a forum/bulletin board-like Web
> interface to mailing lists in Guile and until then stick to pure
> mailing lists.

That's pretty much what discourse is - an attractive web interface to
something like mailing lists, with the option to use a mail client
interface as well as the web interface if you want.

To be clear I am definitely not pushing for this kind of change
(I think I must be quite old-fashioned because it seems to me that
traditional mailing lists work fine), nor am I particularly against it.
I am not sure what it is that caused gnome to move from mailman to
discourse, but I suspect it was to get the more up-to-date feel of a web
interface.  I notice also that the ocaml "mailing list" also uses
discourse, should anyone want to ask them what they get out of it.

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[pelzflorian (Florian Pelz)]

On Wed, 23 Oct 2019 08:48:13 +0200
"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> wrote:
> On Wed, Oct 23, 2019 at 08:16:34AM +0200, Amirouche Boubekki wrote:
> I only know that subscribing to GNOME Discourse required Javascript
> and its mail headers are less pretty compared to mailman.
> 

These are the reasons why I do not like Discourse.

> I am not sure what it is that caused gnome to move from mailman to
> discourse, but I suspect it was to get the more up-to-date feel of a web
> interface.

I quote Emmanuele Bassi, <https://mail.gnome.org/archives/gtk-devel-list/2019-February/msg00001.html>:
> Having a better archive search, a better moderation system, and a
> decent web UI are the major selling points for switching to
> Discourse.

Regards,
Florian

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[pelzflorian (Florian Pelz)]

On Wed, Oct 23, 2019 at 01:25:44PM +0200, pelzflorian (Florian Pelz) wrote:
> On Wed, 23 Oct 2019 08:48:13 +0200
> "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> wrote:
> > On Wed, Oct 23, 2019 at 08:16:34AM +0200, Amirouche Boubekki wrote:
> > I only know that subscribing to GNOME Discourse required Javascript
> > and its mail headers are less pretty compared to mailman.
> > 
> 
> These are the reasons why I do not like Discourse.
> 
> > I am not sure what it is that caused gnome to move from mailman to
> > discourse, but I suspect it was to get the more up-to-date feel of a web
> > interface.
> 
> I quote Emmanuele Bassi, <https://mail.gnome.org/archives/gtk-devel-list/2019-February/msg00001.html>:
> > Having a better archive search, a better moderation system, and a
> > decent web UI are the major selling points for switching to
> > Discourse.
> 

If there isn’t one already, then I would like to start working on a
written in Guile, free software, old-school bulletin board-like
interface, perhaps with a more modern UI design, next week.  I do not
like Discourse and will need something like this anyway for other
projects.  I see there already is guile-email and Mumi.  So far I had
no time looking at either.  I would start next week.

Regards,
Florian

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[tomas]

[-- Attachment #1: Type: text/plain, Size: 249 bytes --]

On Wed, Oct 23, 2019 at 02:33:43PM +0200, pelzflorian (Florian Pelz) wrote:

[...]

> If there isn’t one already, then I would like to start working on a
> written in Guile [...]

Hmmm. I might be your first contributor :)

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[pelzflorian (Florian Pelz)]

On Wed, Oct 23, 2019 at 03:47:21PM +0200, tomas@tuxteam.de wrote:
> On Wed, Oct 23, 2019 at 02:33:43PM +0200, pelzflorian (Florian Pelz) wrote:
> 
> [...]
> 
> > If there isn’t one already, then I would like to start working on a
> > written in Guile [...]
> 
> Hmmm. I might be your first contributor :)
> 
> Cheers
> -- t

That would be welcome.  I will only start next week with looking at
other software
<https://en.wikipedia.org/wiki/Internet_forum_software>.

Regards,
Florian

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[Mikael Djurfeldt]

Florian, would Nala Ginrut's Artanis be a useful framework to base a
bulletin board system on?

https://web-artanis.com/

Den ons 23 okt. 2019 16:15pelzflorian (Florian Pelz) <
pelzflorian@pelzflorian.de> skrev:

> On Wed, Oct 23, 2019 at 03:47:21PM +0200, tomas@tuxteam.de wrote:
> > On Wed, Oct 23, 2019 at 02:33:43PM +0200, pelzflorian (Florian Pelz)
> wrote:
> >
> > [...]
> >
> > > If there isn’t one already, then I would like to start working on a
> > > written in Guile [...]
> >
> > Hmmm. I might be your first contributor :)
> >
> > Cheers
> > -- t
>
> That would be welcome.  I will only start next week with looking at
> other software
> <https://en.wikipedia.org/wiki/Internet_forum_software>.
>
> Regards,
> Florian
>
>

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[pelzflorian (Florian Pelz)]

On Wed, Oct 23, 2019 at 09:09:46PM +0200, Mikael Djurfeldt wrote:
> Florian, would Nala Ginrut's Artanis be a useful framework to base a
> bulletin board system on?
> 
> https://web-artanis.com/
> 

Thank you for reminding me.  I had thought of Artanis, but only had a
cursory look at it before.  (Please do not overestimate my limited
experience here.)  Its functionality seems appropriate.  I will take a
more thorough look at its extensive features and documentation.

Regards,
Florian

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[Zelphir Kaltstahl]

On 10/23/19 2:33 PM, pelzflorian (Florian Pelz) wrote:
> On Wed, Oct 23, 2019 at 01:25:44PM +0200, pelzflorian (Florian Pelz) wrote:
>> On Wed, 23 Oct 2019 08:48:13 +0200
>> "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> wrote:
>>> On Wed, Oct 23, 2019 at 08:16:34AM +0200, Amirouche Boubekki wrote:
>>> I only know that subscribing to GNOME Discourse required Javascript
>>> and its mail headers are less pretty compared to mailman.
>>>
>> These are the reasons why I do not like Discourse.
>>
>>> I am not sure what it is that caused gnome to move from mailman to
>>> discourse, but I suspect it was to get the more up-to-date feel of a web
>>> interface.
>> I quote Emmanuele Bassi, <https://mail.gnome.org/archives/gtk-devel-list/2019-February/msg00001.html>:
>>> Having a better archive search, a better moderation system, and a
>>> decent web UI are the major selling points for switching to
>>> Discourse.
> If there isn’t one already, then I would like to start working on a
> written in Guile, free software, old-school bulletin board-like
> interface, perhaps with a more modern UI design, next week.  I do not
> like Discourse and will need something like this anyway for other
> projects.  I see there already is guile-email and Mumi.  So far I had
> no time looking at either.  I would start next week.
>
> Regards,
> Florian

It would be an interesting project, for an example of how to do a Guile
server side. What kind of library/framework/tool would you use for the
server side? I think the standard library webserver is still very bare
bones. So far I've not tried GNU Artanis. Would it be a good idea to use
that?

I've created some example code for the standard library web server:

https://gitlab.com/zelphir-kaltstahl-projects/guile-scheme-tutorials-and-examples/tree/dev/web-development/using-guile-webserver

But it has not progressed very far.

Regards,
Zelphir

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[Nala Ginrut]

Hi folks!
Artanis has been using in product, that is to say, working stable and keep
maintaining. Artanis aims for rapid development just like Ruby on Rails. So
that you may try your different ideas quickly.

If anyone is willing to try Artanis for the modern forum of Guile
community, I'd like to provide free technical support, free as in free
beer. :-)

Best regards.


Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> 于 2019年10月24日周四 05:42写道：

>
> On 10/23/19 2:33 PM, pelzflorian (Florian Pelz) wrote:
> > On Wed, Oct 23, 2019 at 01:25:44PM +0200, pelzflorian (Florian Pelz)
> wrote:
> >> On Wed, 23 Oct 2019 08:48:13 +0200
> >> "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> wrote:
> >>> On Wed, Oct 23, 2019 at 08:16:34AM +0200, Amirouche Boubekki wrote:
> >>> I only know that subscribing to GNOME Discourse required Javascript
> >>> and its mail headers are less pretty compared to mailman.
> >>>
> >> These are the reasons why I do not like Discourse.
> >>
> >>> I am not sure what it is that caused gnome to move from mailman to
> >>> discourse, but I suspect it was to get the more up-to-date feel of a
> web
> >>> interface.
> >> I quote Emmanuele Bassi, <
> https://mail.gnome.org/archives/gtk-devel-list/2019-February/msg00001.html
> >:
> >>> Having a better archive search, a better moderation system, and a
> >>> decent web UI are the major selling points for switching to
> >>> Discourse.
> > If there isn’t one already, then I would like to start working on a
> > written in Guile, free software, old-school bulletin board-like
> > interface, perhaps with a more modern UI design, next week.  I do not
> > like Discourse and will need something like this anyway for other
> > projects.  I see there already is guile-email and Mumi.  So far I had
> > no time looking at either.  I would start next week.
> >
> > Regards,
> > Florian
>
> It would be an interesting project, for an example of how to do a Guile
> server side. What kind of library/framework/tool would you use for the
> server side? I think the standard library webserver is still very bare
> bones. So far I've not tried GNU Artanis. Would it be a good idea to use
> that?
>
> I've created some example code for the standard library web server:
>
>
> https://gitlab.com/zelphir-kaltstahl-projects/guile-scheme-tutorials-and-examples/tree/dev/web-development/using-guile-webserver
>
> But it has not progressed very far.
>
> Regards,
> Zelphir
>
>
>

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[pelzflorian (Florian Pelz)]

Thank you kindly to you for your offers and to Nala for your amazing
software and documentation.  I will get back to you.

Regards,
Florian

mailmam, web bridge, forum, p2p (was: Diversification)

[Amirouche Boubekki]

Le jeu. 24 oct. 2019 à 03:01, Nala Ginrut <nalaginrut@gmail.com> a écrit :
>
> Hi folks!
> Artanis has been using in product, that is to say, working stable and keep
> maintaining. Artanis aims for rapid development just like Ruby on Rails. So
> that you may try your different ideas quickly.
>
> If anyone is willing to try Artanis for the modern forum of Guile
> community, I'd like to provide free technical support, free as in free
> beer. :-)
>
> Best regards.
>
>
> Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> 于 2019年10月24日周四 05:42写道：
>
> >
> > On 10/23/19 2:33 PM, pelzflorian (Florian Pelz) wrote:
> > > On Wed, Oct 23, 2019 at 01:25:44PM +0200, pelzflorian (Florian Pelz)
> > wrote:
> > >> On Wed, 23 Oct 2019 08:48:13 +0200
> > >> "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> wrote:
> > >>> On Wed, Oct 23, 2019 at 08:16:34AM +0200, Amirouche Boubekki wrote:
> > >>> I only know that subscribing to GNOME Discourse required Javascript
> > >>> and its mail headers are less pretty compared to mailman.
> > >>>
> > >> These are the reasons why I do not like Discourse.
> > >>
> > >>> I am not sure what it is that caused gnome to move from mailman to
> > >>> discourse, but I suspect it was to get the more up-to-date feel of a
> > web
> > >>> interface.
> > >> I quote Emmanuele Bassi, <
> > https://mail.gnome.org/archives/gtk-devel-list/2019-February/msg00001.html
> > >:
> > >>> Having a better archive search, a better moderation system, and a
> > >>> decent web UI are the major selling points for switching to
> > >>> Discourse.
> > > If there isn’t one already, then I would like to start working on a
> > > written in Guile, free software, old-school bulletin board-like
> > > interface, perhaps with a more modern UI design, next week.  I do not
> > > like Discourse and will need something like this anyway for other
> > > projects.  I see there already is guile-email and Mumi.  So far I had
> > > no time looking at either.  I would start next week.
> > >
> > > Regards,
> > > Florian
> >
> > It would be an interesting project, for an example of how to do a Guile
> > server side. What kind of library/framework/tool would you use for the
> > server side? I think the standard library webserver is still very bare
> > bones. So far I've not tried GNU Artanis. Would it be a good idea to use
> > that?
> >
> > I've created some example code for the standard library web server:
> >
> >
> > https://gitlab.com/zelphir-kaltstahl-projects/guile-scheme-tutorials-and-examples/tree/dev/web-development/using-guile-webserver
> >
> > But it has not progressed very far.
> >
> > Regards,
> > Zelphir
> >
> >
> >

Last time I checked the security requirements for web application that
do not rely on JavaScript was too complicated. I preferred to forget
about it.

See https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html

The easiest path is (was?) to rely on a token sent by JavaScript.
Meanwhile JavaScript brings other problems... It seems to me the
browser paradigm with the _JavaScript_ wanna be sandbox is the wrong
way forward. I would much prefer the modern approach where a peer
expose an API and people build clients.

There is proof of concept bulletin board using gnunet
https://git.gnunet.org/gnunet-guile2.git/tree/prototypes/c3b2

-- 
Amirouche ~ https://hyper.dev

Re: mailmam, web bridge, forum, p2p (was: Diversification)

[pelzflorian (Florian Pelz)]

[-- Attachment #1: Type: text/plain, Size: 3749 bytes --]

On Thu, Oct 24, 2019 at 11:35:52AM +0200, Amirouche Boubekki wrote:
> Last time I checked the security requirements for web application that
> do not rely on JavaScript was too complicated. I preferred to forget
> about it.
> 
> See https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
> 
> The easiest path is (was?) to rely on a token sent by JavaScript.
> Meanwhile JavaScript brings other problems...


I refuse to believe Javascript is in any way necessary.  The link you
provided contains all information I previously had of tokens and more;
it is a good reference.  I did not know login CSRF before, it is very
relevant, thank you.  My current impression of best practice fits what
is described at the site you linked under “Disclosure of Token in
URL”:

Ordinary HTTP cookies are bad practice for session tokens because of
CSRF.  If you want a normal link to another page on your site but
retain the login session, you should not use cookies for that.
Session tokens must therefore be supplied in HTTP parameters (GET or
POST).  So when a logged in user makes a request, all hyperlinks in
the HTML response (except logout) need to have their HTML code
rewritten by the dynamic web server to contain the session token in
the GET parameters.  Similarly, all POST forms should contain the
session token as a parameter value.  Thus the session token is only
supplied in GET or POST requests from the same site and same session
and no CSRF is possible anymore.  Since the URL used in a GET request
will be exposed to the user, the session token should be invalidated
after verification and the response should contain a new session token
in its HTML code for hyperlinks and forms.  The downside is that URLs
are less pretty but meh…

Invalidating tokens requires the server to store for each registered
user the current session id and the timestamp until which the session
id is valid.  The same user could not be logged in simultaneously from
multiple browsers.  To enable multiple simultaneous logins by the same
user, the server could instead store more sessions than it has users,
but this might enable denial of service.  Or the server could instead
use what the site you linked describes as “Encryption based Token
Pattern” to not have this problem.  But then no token invalidation is
possible, so instead of GET requests we would need to use HTTP POST
for every hyperlink which is sometimes bad for the browser to deal
with.

Because of login CSRF the Referer header should also be verified for
all links internal to the website (external links should strip the
Referer header via redirect pages similar to what the code attached to
this mail does).

I do not know what Artanis does currently.  I will check next week.


> It seems to me the
> browser paradigm with the _JavaScript_ wanna be sandbox is the wrong
> way forward.

A sandbox does not guarantee security from hardware bugs like
Rowhammer or Spectre (but neither do multi user setups).  Also a
sandbox does not protect your computer from mining bitcoins for
someone else in a sandboxed environment.  It also permits bad,
battery-draining code.  Perhaps more importantly, JavaScript has all
kinds of privacy implications and encourages users to run nonfree
code.

> I would much prefer the modern approach where a peer
> expose an API and people build clients.
>

Many enterprises offer not APIs but non-downloadable JavaScript
service as a software substitute.

> There is proof of concept bulletin board using gnunet
> https://git.gnunet.org/gnunet-guile2.git/tree/prototypes/c3b2
>

That is interesting.  I will check.

Regards,
Florian

[-- Attachment #2: web-redirector.scm --]
[-- Type: application/vnd.lotus-screencam, Size: 3631 bytes --]

Re: mailmam, web bridge, forum, p2p (was: Diversification)

[Nala Ginrut]

On Thu, Oct 24, 2019 at 8:30 PM pelzflorian (Florian Pelz) <
pelzflorian@pelzflorian.de> wrote:

> Because of login CSRF the Referer header should also be verified for
> all links internal to the website (external links should strip the
> Referer header via redirect pages similar to what the code attached to
> this mail does).
>
> I do not know what Artanis does currently.  I will check next week.
>
>
The current Artanis will check both session token (from cookies) and the
client IP.
This method was blamed to be overkilled because some users may be in the
same LAN with a unique external IP.
But I think IPv6 will cover this world finally, so I think this would be
the best way to go.
Of course, there's no conflict to add extra verification token. Patches or
proposals are welcome. ;-)

Best regards.

Re: mailmam, web bridge, forum, p2p (was: Diversification)

[Zelphir Kaltstahl]

Hi Nala!

I have a question regarding this IP check.

Does this mean that both, the IP address and (logical and) the cookie
need to be correct, or is it an inclusive logical or?

I sometimes find myself switching location of the server of the VPN I am
using. In such a case, would I still be logged in, based on the correct
cookie, or would I be logged out, because my IP address does not match
my previous address?

Regards,

Zelphir

On 10/24/19 4:15 PM, Nala Ginrut wrote:
> On Thu, Oct 24, 2019 at 8:30 PM pelzflorian (Florian Pelz) <
> pelzflorian@pelzflorian.de> wrote:
>
>> Because of login CSRF the Referer header should also be verified for
>> all links internal to the website (external links should strip the
>> Referer header via redirect pages similar to what the code attached to
>> this mail does).
>>
>> I do not know what Artanis does currently.  I will check next week.
>>
>>
> The current Artanis will check both session token (from cookies) and the
> client IP.
> This method was blamed to be overkilled because some users may be in the
> same LAN with a unique external IP.
> But I think IPv6 will cover this world finally, so I think this would be
> the best way to go.
> Of course, there's no conflict to add extra verification token. Patches or
> proposals are welcome. ;-)
>
> Best regards.

Re: mailmam, web bridge, forum, p2p (was: Diversification)

[Nala Ginrut]

Yes, you need to login if you change IP, but the last IP keeps session.
BTW, encoding token in URL is bad for SEO.

Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> 于 2019年10月25日周五 01:44写道：

> Hi Nala!
>
> I have a question regarding this IP check.
>
> Does this mean that both, the IP address and (logical and) the cookie
> need to be correct, or is it an inclusive logical or?
>
> I sometimes find myself switching location of the server of the VPN I am
> using. In such a case, would I still be logged in, based on the correct
> cookie, or would I be logged out, because my IP address does not match
> my previous address?
>
> Regards,
>
> Zelphir
>
> On 10/24/19 4:15 PM, Nala Ginrut wrote:
> > On Thu, Oct 24, 2019 at 8:30 PM pelzflorian (Florian Pelz) <
> > pelzflorian@pelzflorian.de> wrote:
> >
> >> Because of login CSRF the Referer header should also be verified for
> >> all links internal to the website (external links should strip the
> >> Referer header via redirect pages similar to what the code attached to
> >> this mail does).
> >>
> >> I do not know what Artanis does currently.  I will check next week.
> >>
> >>
> > The current Artanis will check both session token (from cookies) and the
> > client IP.
> > This method was blamed to be overkilled because some users may be in the
> > same LAN with a unique external IP.
> > But I think IPv6 will cover this world finally, so I think this would be
> > the best way to go.
> > Of course, there's no conflict to add extra verification token. Patches
> or
> > proposals are welcome. ;-)
> >
> > Best regards.
>
>

Re: mailmam, web bridge, forum, p2p

[Mike Gerwitz]

[-- Attachment #1: Type: text/plain, Size: 2237 bytes --]

On Thu, Oct 24, 2019 at 14:30:23 +0200, pelzflorian (Florian Pelz) wrote:
> Ordinary HTTP cookies are bad practice for session tokens because of
> CSRF.  If you want a normal link to another page on your site but
> retain the login session, you should not use cookies for that.
> Session tokens must therefore be supplied in HTTP parameters (GET or
> POST).  So when a logged in user makes a request, all hyperlinks in
> the HTML response (except logout) need to have their HTML code
> rewritten by the dynamic web server to contain the session token in
> the GET parameters.  Similarly, all POST forms should contain the
> session token as a parameter value.  Thus the session token is only
> supplied in GET or POST requests from the same site and same session
> and no CSRF is possible anymore.  Since the URL used in a GET request
> will be exposed to the user, the session token should be invalidated
> after verification and the response should contain a new session token
> in its HTML code for hyperlinks and forms.  The downside is that URLs
> are less pretty but meh…

CSRF mitigation and session tokens are separate concerns.  You can mix
them, but that leads to complexity.  The typical mitigation is to just
to use nonces for sensitive requests (e.g. place the nonce in a hidden
form field to be posted with the form itself).  If you're using nonces,
there's nothing wrong with cookies.

Passing session tokens via GET requests is a bad idea, because that
leaks the token.  You can change the session token after every single
request, but that leads to a host of other issues: you can't have
multiple tabs open to the same site, you have to deal with synchronizing
the new token potentially across multiple systems which complicates load
balancing and SSO, etc.

Checking the referrer isn't a good security measure.  For example, if
the legitimate referrer were vulnerable to XSS, open redirects, or a
host of other vulnerabilities, then an attacker could circumvent it by
having the CSRF attack originate from that website.

-- 
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B  2388 FEF6 3574 5E6F 6D05
https://mikegerwitz.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: mailmam, web bridge, forum, p2p

[tomas]

[-- Attachment #1: Type: text/plain, Size: 226 bytes --]

On Thu, Oct 24, 2019 at 09:39:04PM -0400, Mike Gerwitz wrote:

thanks for your good overview... a question

> Passing session tokens via GET requests is a bad idea, because that
> leaks the token.

Even in https?

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: mailmam, web bridge, forum, p2p

[Nala Ginrut]

On Sat, Oct 26, 2019 at 3:49 PM <tomas@tuxteam.de> wrote:

> On Thu, Oct 24, 2019 at 09:39:04PM -0400, Mike Gerwitz wrote:
>
> thanks for your good overview... a question
>
> > Passing session tokens via GET requests is a bad idea, because that
> > leaks the token.
>
> Even in https?
>

I guess he mean query-string with GET.


>
> Cheers
> -- t
>

Re: mailmam, web bridge, forum, p2p

[tomas]

[-- Attachment #1: Type: text/plain, Size: 654 bytes --]

On Sat, Oct 26, 2019 at 06:35:18PM +0800, Nala Ginrut wrote:
> On Sat, Oct 26, 2019 at 3:49 PM <tomas@tuxteam.de> wrote:
> 
> > On Thu, Oct 24, 2019 at 09:39:04PM -0400, Mike Gerwitz wrote:
> >
> > thanks for your good overview... a question
> >
> > > Passing session tokens via GET requests is a bad idea, because that
> > > leaks the token.
> >
> > Even in https?
> >
> 
> I guess he mean query-string with GET.

That's another possibility. Both of them end up encrypted in HTTPS
anyway. I decided against query string at that time because that
saved me quite a bit of template substitution (use relative links).

Cheers
-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: mailmam, web bridge, forum, p2p

[Mike Gerwitz]

[-- Attachment #1: Type: text/plain, Size: 1546 bytes --]

To make sure I see replies, please include me in the recipient list (not
just the mailing list).  I missed this at first.

On Sat, Oct 26, 2019 at 09:48:37 +0200, tomas@tuxteam.de wrote:
>> Passing session tokens via GET requests is a bad idea, because that
>> leaks the token.
>
> Even in https?

Transport is only part of the problem.  Query parameters are also leaked
to webserver access logs; they can leak to 3rd party logs via the
referrer header (I sometimes see sensitive data in my webserver logs
from other domains); they're retained in browser history and written to
disk; may show up in proxy logs (e.g. when passing through load
balancers); could be easily pasted unwittingly to third parties (e.g. a
user sharing a link with someone else); etc.

Back in what feels like a previous lifetime by now, I used to do a lot
of work with phpBB2, which had an option to either store sessions in
cookies or place PHPSESSID in the URL.  It modified every link to
include a session id.  It tried to mitigate the issue by checking the
source IP address, but if you were logged on the same network (e.g. in
the same place of employment; school; library; etc), then sharing a link
would lead to session hijacking.

Such link rewriting schemes also cause other types of problems.  For
example, you may be able to cache most of the generated HTML (except for
e.g. the header) regardless of what user is logged in.  But if you have
to inject tokens into all links, that type of caching isn't useful.

-- 
Mike Gerwitz

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: mailmam, web bridge, forum, p2p

[Mike Gerwitz]

[-- Attachment #1: Type: text/plain, Size: 1529 bytes --]

On Sun, Oct 27, 2019 at 00:50:17 -0400, Mike Gerwitz wrote:
> On Sat, Oct 26, 2019 at 09:48:37 +0200, tomas@tuxteam.de wrote:
>>> Passing session tokens via GET requests is a bad idea, because that
>>> leaks the token.
>>
>> Even in https?

[...]

> Back in what feels like a previous lifetime by now, I used to do a lot
> of work with phpBB2, which had an option to either store sessions in
> cookies or place PHPSESSID in the URL.  It modified every link to
> include a session id.  It tried to mitigate the issue by checking the
> source IP address, but if you were logged on the same network (e.g. in
> the same place of employment; school; library; etc), then sharing a link
> would lead to session hijacking.

Since I was in the mindset of leaking information, I forgot to mention
another negative side-effect of including tokens as query strings: it
can turn link sharing into a weapon using session fixation.  E.g. I
could create an account, send a link to you with my session token, and
you may then be logged into my account.  The user may then perform an
action that may benefit the attacker (or the action could be part of the
URL).

This is sometimes used as a poor-man's SSO. :x  It can also work with
POSTs: direct the user to an auto-submitting form.

Cookies are better suited for storing session tokens---you cannot set
cookie values for other domains without some other type of exploit
(e.g. XSS, but your cookies best be set to HTTP-only to mitigate that).

-- 
Mike Gerwitz

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: mailmam, web bridge, forum, p2p

[tomas]

[-- Attachment #1: Type: text/plain, Size: 2200 bytes --]

On Sun, Oct 27, 2019 at 01:32:54AM -0400, Mike Gerwitz wrote:

[...]

> > Back in what feels like a previous lifetime by now, I used to do a lot
> > of work with phpBB2, which had an option to either store sessions in
> > cookies or place PHPSESSID in the URL.  It modified every link to
> > include a session id [...]

> Since I was in the mindset of leaking information, I forgot to mention
> another negative side-effect of including tokens as query strings: it
> can turn link sharing into a weapon using session fixation.  E.g. I
> could create an account, send a link to you with my session token, and
> you may then be logged into my account.

Actually there are two scenarios: User A (say Alice) "has" the session
and passes a link to B (Bob), session token included.

This could be negligence, and now Bob might do something nasty with
Alice's session (e.g. go into a shopping spree)...

>                                          The user may then perform an
> action that may benefit the attacker (or the action could be part of the
> URL).

...but you seem to imply that there's a reverse scenario, where Alice
does something nasty to Bob?

> This is sometimes used as a poor-man's SSO. :x  It can also work with
> POSTs: direct the user to an auto-submitting form.

Yes, you could take your "session token" with you, to another computer,
but this seems somewhat fragile [1].

> Cookies are better suited for storing session tokens---you cannot set
> cookie values for other domains without some other type of exploit
> (e.g. XSS, but your cookies best be set to HTTP-only to mitigate that).

Cookies are, after all, client-side data. The browser might not allow
you to do something, but you can engineer all sort of HTTP requests:
that means the server has to do its own sanity checks anyway.

Cheers

[1] That's why I'd go for a fairly strict session expiry; perhaps
   (but I haven't played with it in practice!) you'd need transaction
   tokens instead (as those continuation based thingies use), which
   can be even more short-lived. Perhaps even some correlation
   between token and client profile (IP address, etc.).

-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: mailmam, web bridge, forum, p2p

[tomas]

[-- Attachment #1: Type: text/plain, Size: 2767 bytes --]

On Sun, Oct 27, 2019 at 12:50:17AM -0400, Mike Gerwitz wrote:
> To make sure I see replies, please include me in the recipient list (not
> just the mailing list).  I missed this at first.
> 
> On Sat, Oct 26, 2019 at 09:48:37 +0200, tomas@tuxteam.de wrote:
> >> Passing session tokens via GET requests is a bad idea, because that
> >> leaks the token.
> >
> > Even in https?

Thanks for this complete account. I appreciate it very much!

> Transport is only part of the problem.
> Query parameters are also leaked to webserver access logs;

That's true -- but I'd call that "category B". The server realm
is full with sensitive data, and the logs are part of that.

> they can leak to 3rd party logs via the referrer header (I
> sometimes see sensitive data in my webserver logs from other
> domains);

That's more serious ("category A") -- third parties get to look
into sensitive data. The application has to take care of links
pointing to the "outside".

If we're trying to pull off this, we'll have to think hard
about this one.

> they're retained in browser history and written to disk;

Again "category B". The browser's cookie jar is, after all,
also there for all to see. As a forensics analyst or a data
"thieve", I'd take with me the whole browser subdir, anyway.

> may show up in proxy logs (e.g. when passing through load
> balancers); could be easily pasted unwittingly to third parties (e.g. a
> user sharing a link with someone else); etc.

Only for plain http (unless it's one of those corporate proxies
with an "open-all" root certificate, that is).

> Back in what feels like a previous lifetime by now, I used to do a lot
> of work with phpBB2, which had an option to either store sessions in
> cookies or place PHPSESSID in the URL.  It modified every link to
> include a session id.  It tried to mitigate the issue by checking the
> source IP address, but if you were logged on the same network (e.g. in
> the same place of employment; school; library; etc), then sharing a link
> would lead to session hijacking.

This all is in the context of plain http, I guess.

> Such link rewriting schemes also cause other types of problems.  For
> example, you may be able to cache most of the generated HTML (except for
> e.g. the header) regardless of what user is logged in.  But if you have
> to inject tokens into all links, that type of caching isn't useful.

Yes. But this has lost most of its bite in the last decade or
so. Machines have increased in power (speed, RAM) faster than
the network. Apart from really high-volume sites, where you
start thinking about load balancers, CDNs, etc. I think a bit
of server-side template substitution will drown in the noise.

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: mailmam, web bridge, forum, p2p

[Keith Wright]

Mike Gerwitz <mtg@gnu.org> writes:

> To make sure I see replies, please include me in the recipient list (not
> just the mailing list).  I missed this at first.
>
> On Sat, Oct 26, 2019 at 09:48:37 +0200, tomas@tuxteam.de wrote:
>>> Passing session tokens via GET requests is a bad idea, because that
>>> leaks the token.

Actually, if you are going to have an extended conversation
between two people that has little to do with Guile,
consider taking it off the mailing list entirely.

   -- Keith 

Re: mailmam, web bridge, forum, p2p

[Zelphir Kaltstahl]

On 10/27/19 3:26 PM, Keith Wright wrote:
> Mike Gerwitz <mtg@gnu.org> writes:
>
>> To make sure I see replies, please include me in the recipient list (not
>> just the mailing list).  I missed this at first.
>>
>> On Sat, Oct 26, 2019 at 09:48:37 +0200, tomas@tuxteam.de wrote:
>>>> Passing session tokens via GET requests is a bad idea, because that
>>>> leaks the token.
> Actually, if you are going to have an extended conversation
> between two people that has little to do with Guile,
> consider taking it off the mailing list entirely.
>
>    -- Keith 
>
Hi Keith,

I understand your point (everyone gets emails …), but at the same time I
find this quite educational. It would be great, if at the end there was
some documentation why one approach was chosen, with all the up- and
downsides of the approaches discussed, if this is not available on the
mailing list : )

Regards,

Zelphir

Re: mailmam, web bridge, forum, p2p (was: Diversification)

[pelzflorian (Florian Pelz)]

On Fri, Oct 25, 2019 at 07:42:41AM +0800, Nala Ginrut wrote:
> Yes, you need to login if you change IP, but the last IP keeps session.

Does checking the IP enhance security in any way?  There are some
(few) reasons IPs may change.

> BTW, encoding token in URL is bad for SEO.
> 

That is interesting, I did not think of that.  Then again, browsing
the mailing list would be possible without login, i.e. without token,
so URLs would be clean for a search engine crawler.  I do not know if
crawlers should ever have a session on other Artanis sites.


On Thu, Oct 24, 2019 at 09:39:04PM -0400, Mike Gerwitz wrote:
> CSRF mitigation and session tokens are separate concerns.  You can mix
> them, but that leads to complexity.  The typical mitigation is to just
> to use nonces for sensitive requests (e.g. place the nonce in a hidden
> form field to be posted with the form itself).  If you're using nonces,
> there's nothing wrong with cookies.
> 
> Passing session tokens via GET requests is a bad idea, because that
> leaks the token.  You can change the session token after every single
> request, but that leads to a host of other issues: you can't have
> multiple tabs open to the same site, you have to deal with synchronizing
> the new token potentially across multiple systems which complicates load
> balancing and SSO, etc.
> 

So you would use both a cookie to retain login state and then only for
sensitive requests additionally use nonces to prevent CSRF.  Would you
use POST for all (sensitive) requests after login?

I had not even thought of SSO.  Do we want that?  Can we hope for
using that?


> Checking the referrer isn't a good security measure.  For example, if
> the legitimate referrer were vulnerable to XSS, open redirects, or a
> host of other vulnerabilities, then an attacker could circumvent it by
> having the CSRF attack originate from that website.
> 

I read Amirouche’s owasp link which describes checking the referer
only as an additional “Defense in Depth” security measure in the hope
of preventing what it calls login CSRF, i.e. giving someone a login
from someone else without them noticing (if I understand correctly).
A cookie would prevent that anyway, I suppose.

Regards,
Florian

Re: mailmam, web bridge, forum, p2p (was: Diversification)

[Nala Ginrut]

On Fri, Oct 25, 2019 at 2:08 PM pelzflorian (Florian Pelz) <
pelzflorian@pelzflorian.de> wrote:

> On Fri, Oct 25, 2019 at 07:42:41AM +0800, Nala Ginrut wrote:
> > Yes, you need to login if you change IP, but the last IP keeps session.
>
> Does checking the IP enhance security in any way?  There are some
> (few) reasons IPs may change.
>

We don't chase the effect that one policy solves all problems.
Checking IP can only solve certain general problems. For example, the
stolen token can not be used to login from another machine.


> That is interesting, I did not think of that.  Then again, browsing
> the mailing list would be possible without login, i.e. without token,
> so URLs would be clean for a search engine crawler.  I do not know if
> crawlers should ever have a session on other Artanis sites.
>
>
I'm talking about the general cases since Artanis is not only for
mailing-list browsing.
The purpose is to explain why Artanis choose the policy.
In Artanis, you may use a customized method for that.

Best regards.

Re: mailmam, web bridge, forum, p2p

[Mike Gerwitz]

[-- Attachment #1: Type: text/plain, Size: 3391 bytes --]

On Fri, Oct 25, 2019 at 08:08:45 +0200, pelzflorian (Florian Pelz) wrote:
> On Thu, Oct 24, 2019 at 09:39:04PM -0400, Mike Gerwitz wrote:
>> CSRF mitigation and session tokens are separate concerns.  You can mix
>> them, but that leads to complexity.  The typical mitigation is to just
>> to use nonces for sensitive requests (e.g. place the nonce in a hidden
>> form field to be posted with the form itself).  If you're using nonces,
>> there's nothing wrong with cookies.
>> 
>> Passing session tokens via GET requests is a bad idea, because that
>> leaks the token.  You can change the session token after every single
>> request, but that leads to a host of other issues: you can't have
>> multiple tabs open to the same site, you have to deal with synchronizing
>> the new token potentially across multiple systems which complicates load
>> balancing and SSO, etc.
>> 
>
> So you would use both a cookie to retain login state and then only for
> sensitive requests additionally use nonces to prevent CSRF.  Would you
> use POST for all (sensitive) requests after login?

GET requests are supposed to retrieve information, not modify it, and
should be indempotent.  Since they should have no meaningful
side-effects, CSRF shouldn't have any meaningful action to
exploit.  Whether or not that's true in practice of course depends on
how the site was developed.  If a GET request does have some meaningful
side-effect (e.g. maybe it logs the action and that event can influence
some other part of the system), then it may need to be mitigated by
including a nonce.

GET requests shouldn't contain sensitive data because they will appear
in browser history; server logs; referral headers; etc.

> I had not even thought of SSO.  Do we want that?  Can we hope for
> using that?

I don't know, in the context of Guile; I haven't fully followed the
conversation; you just happened to say something that I wanted to chime
in on. :)  I was providing a general example in my experience as a
professional web developer.  There are other reasons as well.

>> Checking the referrer isn't a good security measure.  For example, if
>> the legitimate referrer were vulnerable to XSS, open redirects, or a
>> host of other vulnerabilities, then an attacker could circumvent it by
>> having the CSRF attack originate from that website.
>> 
>
> I read Amirouche’s owasp link which describes checking the referer
> only as an additional “Defense in Depth” security measure in the hope
> of preventing what it calls login CSRF, i.e. giving someone a login
> from someone else without them noticing (if I understand correctly).
> A cookie would prevent that anyway, I suppose.

It's a potentially valid defense-in-depth strategy, but isn't sufficient
on its own.  I personally don't see much value in it.  If a
properly-implemented nonce-based mitigation strategy fails, then the
attacker is likely in a situation where the referrer is no longer a
barrier (e.g. they have access to the page and can inject scripts or
just hijack the session).  Mitigating session hijacking is extremely
difficult in this scenario---you can't perform IP-based checks because
users often change IPs (e.g. on mobile networks, VPN, Tor, etc).  You
can't rely on any information sent by the client because it can be
spoofed by the attacker.

-- 
Mike Gerwitz

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: mailmam, web bridge, forum, p2p

[pelzflorian (Florian Pelz)]

On Sat, Oct 26, 2019 at 12:31:34AM -0400, Mike Gerwitz wrote:
> On Fri, Oct 25, 2019 at 08:08:45 +0200, pelzflorian (Florian Pelz) wrote:
> > So you would use both a cookie to retain login state and then only for
> > sensitive requests additionally use nonces to prevent CSRF.  Would you
> > use POST for all (sensitive) requests after login?
> 
> GET requests are supposed to retrieve information, not modify it, and
> should be indempotent.  Since they should have no meaningful
> side-effects, CSRF shouldn't have any meaningful action to
> exploit.

You are right.  That makes sense.  We need not abstain from cookies
and with cookies we can have GET requests retain session state and
then for anything sensitive use a nonce, whether GET or POST,
i.e. write code for links to include a nonce and verify nonces.
Thank you!



> Whether or not that's true in practice of course depends on
> how the site was developed.  If a GET request does have some meaningful
> side-effect (e.g. maybe it logs the action and that event can influence
> some other part of the system), then it may need to be mitigated by
> including a nonce.
> 

Probably for a mailing list interface, there should not be such a log annyway.
We will have to remember session cookies are fine, so we can have all
the nice things like multiple tabs, but making a sensitive request
means using a nonce



> >> Checking the referrer isn't a good security measure.  For example, if
> >> the legitimate referrer were vulnerable to XSS, open redirects, or a
> >> host of other vulnerabilities, then an attacker could circumvent it by
> >> having the CSRF attack originate from that website.
> >> 
> >
> > I read Amirouche’s owasp link which describes checking the referer
> > only as an additional “Defense in Depth” security measure in the hope
> > of preventing what it calls login CSRF, i.e. giving someone a login
> > from someone else without them noticing (if I understand correctly).
> > A cookie would prevent that anyway, I suppose.
> 
> It's a potentially valid defense-in-depth strategy, but isn't sufficient
> on its own.  I personally don't see much value in it.  If a
> properly-implemented nonce-based mitigation strategy fails, then the
> attacker is likely in a situation where the referrer is no longer a
> barrier (e.g. they have access to the page and can inject scripts or
> just hijack the session).  Mitigating session hijacking is extremely
> difficult in this scenario---you can't perform IP-based checks because
> users often change IPs (e.g. on mobile networks, VPN, Tor, etc).  You
> can't rely on any information sent by the client because it can be
> spoofed by the attacker.
>

As I understand it, checking the referer should defend against the
attacker sending a user a link where the user is logged in as someone
else.  Cookies prevent that anyway, so if we avoid XSS (which is easy
in Scheme’s SHTML) and do not let others host web workers on the same
domain and such things, no further measures are needed, I think.  In
particular, IP checking would not be needed, but I will think about
that again once I actually have studied Artanis.

Regards,
Florian

Re: mailmam, web bridge, forum, p2p

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]

On Sat, Oct 26, 2019 at 11:35:06AM +0200, pelzflorian (Florian Pelz) wrote:
> On Sat, Oct 26, 2019 at 12:31:34AM -0400, Mike Gerwitz wrote:
> > On Fri, Oct 25, 2019 at 08:08:45 +0200, pelzflorian (Florian Pelz) wrote:
> > > So you would use both a cookie to retain login state and then only for
> > > sensitive requests additionally use nonces to prevent CSRF.  Would you
> > > use POST for all (sensitive) requests after login?
> > 
> > GET requests are supposed to retrieve information, not modify it, and
> > should be indempotent.  Since they should have no meaningful
> > side-effects, CSRF shouldn't have any meaningful action to
> > exploit.
> 
> You are right.  That makes sense.  We need not abstain from cookies
> and with cookies we can have GET requests retain session state and
> then for anything sensitive use a nonce, whether GET or POST,
> i.e. write code for links to include a nonce and verify nonces.
> Thank you!

You can still have session state in the URL and keep GET idempotent
(there might be other reasons to use cookies, though: I've yet to be
convinced ;-)

Cheers
-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: mailmam, web bridge, forum, p2p (was: Diversification)

[tomas]

[-- Attachment #1: Type: text/plain, Size: 673 bytes --]

On Thu, Oct 24, 2019 at 11:35:52AM +0200, Amirouche Boubekki wrote:
> Le jeu. 24 oct. 2019 à 03:01, Nala Ginrut <nalaginrut@gmail.com> a écrit :

[...]

> Last time I checked the security requirements for web application that
> do not rely on JavaScript was too complicated. I preferred to forget
> about it.
> 
> See https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html

Now this is interesting. I still dream of an "application"
which is viable (perhaps with some restrictions) without
any javascript (as Wikipedia and relatives do, BTW). So
I'm interested in such things as above...

Cheers
-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: mailmam, web bridge, forum, p2p (was: Diversification)

[Nala Ginrut]

I've ever tried to write a site for our local community without any JS
code, all auxiliary features include simple animation are implemented with
CSS.
However, I have to say it's painful to write a more complex site. I don't
know if there's any framework for that. I'm too lazy to write all things
manually. But I recommend you try it if you never did. It's interesting.

Best regards.


<tomas@tuxteam.de> 于 2019年10月24日周四 22:58写道：

> On Thu, Oct 24, 2019 at 11:35:52AM +0200, Amirouche Boubekki wrote:
> > Le jeu. 24 oct. 2019 à 03:01, Nala Ginrut <nalaginrut@gmail.com> a
> écrit :
>
> [...]
>
> > Last time I checked the security requirements for web application that
> > do not rely on JavaScript was too complicated. I preferred to forget
> > about it.
> >
> > See
> https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
>
> Now this is interesting. I still dream of an "application"
> which is viable (perhaps with some restrictions) without
> any javascript (as Wikipedia and relatives do, BTW). So
> I'm interested in such things as above...
>
> Cheers
> -- tomás
>

Re: mailmam, web bridge, forum, p2p (was: Diversification)

[tomas]

[-- Attachment #1: Type: text/plain, Size: 674 bytes --]

On Thu, Oct 24, 2019 at 11:03:07PM +0800, Nala Ginrut wrote:
> I've ever tried to write a site for our local community without any JS
> code, all auxiliary features include simple animation are implemented with
> CSS.
> However, I have to say it's painful to write a more complex site. I don't
> know if there's any framework for that. I'm too lazy to write all things
> manually. But I recommend you try it if you never did. It's interesting.

I once did. Long time ago. A simple shop -- no javascript.

All state was coded in the URL. You wouldn't do that these days (at least
not without thinking hard) -- but it worked acceptably. People ordered
things :-)

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: mailmam, web bridge, forum, p2p (was: Diversification)

[Zelphir Kaltstahl]

Hi Tomas!

Do you still remember some of the issues you came across when making
such a shop?

If I am not mistaken, Racket's continuation based webserver does
something like this. It also stores state in the URL, which then looks a
bit strange. I think that state even encodes the continuation.

Regards,

Zelphir


On 10/24/19 5:12 PM, tomas@tuxteam.de wrote:
> On Thu, Oct 24, 2019 at 11:03:07PM +0800, Nala Ginrut wrote:
>> I've ever tried to write a site for our local community without any JS
>> code, all auxiliary features include simple animation are implemented with
>> CSS.
>> However, I have to say it's painful to write a more complex site. I don't
>> know if there's any framework for that. I'm too lazy to write all things
>> manually. But I recommend you try it if you never did. It's interesting.
> I once did. Long time ago. A simple shop -- no javascript.
>
> All state was coded in the URL. You wouldn't do that these days (at least
> not without thinking hard) -- but it worked acceptably. People ordered
> things :-)
>
> Cheers
> -- t

Re: mailmam, web bridge, forum, p2p (was: Diversification)

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1949 bytes --]

On Thu, Oct 24, 2019 at 06:35:50PM +0200, Zelphir Kaltstahl wrote:
> Hi Tomas!
> 
> Do you still remember some of the issues you came across when making
> such a shop?

As I said, it was a pretty simplistic thing:

 - low volume (both customers and inventory)
 - no interest whatsoever in SEO and other things

but it worked pretty well. As basic design principles...

 - I postponed creating session to the last possible
   moment: so the user was browsing the inventory
   basically as a static page, no state encoded;

 - once I had to carry status related to the session
   (i.e. the user dropped the first item into the
   tray), a random session token was generated and
   inserted into the URL. A HTTP redirect then let
   the browser "know" our new common basis.

   I remember chosing an "early" spot at the URL to
   leverage the browser's relative addressing, which
   saves a lot of template substitution in the pages.

   Tokens were expired to avoid abandoned sessions
   piling up

User's feedback was fairly positive: the page felt quick (back
then, the scripts weren't the huge monsters of today, but the
browser's javascript engines weren't as streamlined as today's
either, and the usual bandwidth was a fraction of what is common
these days).

> If I am not mistaken, Racket's continuation based webserver does
> something like this. It also stores state in the URL, which then looks a
> bit strange. I think that state even encodes the continuation.

This is a thing I considered: not to have a per-session
token, but a per-transaction token -- the continuation
idea is pretty cool, because the user can have several
different "histories" of their session running in parallel.

OTOH I tried to imagine the poor webshop user confronted
with that. It sure would confuse the hell out of me ;-)

I think it would take some thinking to tame the less intuitive
parts.

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: mailmam, web bridge, forum, p2p (was: Diversification)

[pelzflorian (Florian Pelz)]

On Sat, Oct 26, 2019 at 10:04:14AM +0200, tomas@tuxteam.de wrote:
>    I remember chosing an "early" spot at the URL to
>    leverage the browser's relative addressing, which
>    saves a lot of template substitution in the pages.
> 

So you encoded the session token not in the GET parameter, but similar
to

https://your-shop.com/<session token>/the/place/on/the/site

?

Regards,
Florian

Re: mailmam, web bridge, forum, p2p (was: Diversification)

[tomas]

[-- Attachment #1: Type: text/plain, Size: 515 bytes --]

On Sat, Oct 26, 2019 at 11:42:47AM +0200, pelzflorian (Florian Pelz) wrote:
> On Sat, Oct 26, 2019 at 10:04:14AM +0200, tomas@tuxteam.de wrote:
> >    I remember chosing an "early" spot at the URL to
> >    leverage the browser's relative addressing, which
> >    saves a lot of template substitution in the pages.
> > 
> 
> So you encoded the session token not in the GET parameter, but similar
> to
> 
> https://your-shop.com/<session token>/the/place/on/the/site

Yes, exactly.

Cheers
-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: mailmam, web bridge, forum, p2p (was: Diversification)

[Mikael Djurfeldt]

It would be nice to be able to run scheme code in the client:

https://github.com/google/schism

They mention "the Webassembly GC proposal". :)

Maybe some day, the Guile compiler could emit WASM? That would mean
supporting multiple VMs.

Mikael

Den tors 24 okt. 2019 18:16Nala Ginrut <nalaginrut@gmail.com> skrev:

> I've ever tried to write a site for our local community without any JS
> code, all auxiliary features include simple animation are implemented with
> CSS.
> However, I have to say it's painful to write a more complex site. I don't
> know if there's any framework for that. I'm too lazy to write all things
> manually. But I recommend you try it if you never did. It's interesting.
>
> Best regards.
>
>
> <tomas@tuxteam.de> 于 2019年10月24日周四 22:58写道：
>
> > On Thu, Oct 24, 2019 at 11:35:52AM +0200, Amirouche Boubekki wrote:
> > > Le jeu. 24 oct. 2019 à 03:01, Nala Ginrut <nalaginrut@gmail.com> a
> > écrit :
> >
> > [...]
> >
> > > Last time I checked the security requirements for web application that
> > > do not rely on JavaScript was too complicated. I preferred to forget
> > > about it.
> > >
> > > See
> >
> https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
> >
> > Now this is interesting. I still dream of an "application"
> > which is viable (perhaps with some restrictions) without
> > any javascript (as Wikipedia and relatives do, BTW). So
> > I'm interested in such things as above...
> >
> > Cheers
> > -- tomás
> >
>

Re: mailmam, web bridge, forum, p2p (was: Diversification)

[Nala Ginrut]

Mikael Djurfeldt <mikael@djurfeldt.com> 于 2019年10月25日周五 19:30写道：

> It would be nice to be able to run scheme code in the client:
>
> https://github.com/google/schism
>
> They mention "the Webassembly GC proposal". :)
>
> Maybe some day, the Guile compiler could emit WASM? That would mean
> supporting multiple VMs.
>

That's my dream for years, fortunately, it will come true, just the matter
of time. Thanks WASM.
Schism generates WASM binary directly. But actually, we may just generate
standard WAT format which is s-expr, and can be convert to WASM by wat2wasm.
And fortunately, WASM has standard low-level system API spec now, which is
called WASI.
I haven't figured out the continuation in WASM. But I saw somebody raised
the topic.

Best regards.



> Mikael
>
> Den tors 24 okt. 2019 18:16Nala Ginrut <nalaginrut@gmail.com> skrev:
>
>> I've ever tried to write a site for our local community without any JS
>> code, all auxiliary features include simple animation are implemented with
>> CSS.
>> However, I have to say it's painful to write a more complex site. I don't
>> know if there's any framework for that. I'm too lazy to write all things
>> manually. But I recommend you try it if you never did. It's interesting.
>>
>> Best regards.
>>
>>
>> <tomas@tuxteam.de> 于 2019年10月24日周四 22:58写道：
>>
>> > On Thu, Oct 24, 2019 at 11:35:52AM +0200, Amirouche Boubekki wrote:
>> > > Le jeu. 24 oct. 2019 à 03:01, Nala Ginrut <nalaginrut@gmail.com> a
>> > écrit :
>> >
>> > [...]
>> >
>> > > Last time I checked the security requirements for web application that
>> > > do not rely on JavaScript was too complicated. I preferred to forget
>> > > about it.
>> > >
>> > > See
>> >
>> https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
>> >
>> > Now this is interesting. I still dream of an "application"
>> > which is viable (perhaps with some restrictions) without
>> > any javascript (as Wikipedia and relatives do, BTW). So
>> > I'm interested in such things as above...
>> >
>> > Cheers
>> > -- tomás
>> >
>>
>

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[Joshua Branson via General Guile related discussions]

You will probably want to borrow this code about how to decode byte
vectors in case you ever need to do any processing of POST requests:

https://notabug.org/jbranso/autoassign/src/master/decode.scm


It should probably be included in the guile src.

Thanks,

Joshua

P.S.  I did not create that file.  I just found it elsewhere.

-- 
Joshua Branson
Sent from Emacs and Gnus

Re: Web development

[Zelphir Kaltstahl]

(If I understand correctly, this is "Re: Web development"? Changed the
subject.)

Hi Joshua!

On 05.09.20 08:15, Joshua Branson via General Guile related discussions
wrote:
> You will probably want to borrow this code about how to decode byte
> vectors in case you ever need to do any processing of POST requests:
>
> https://notabug.org/jbranso/autoassign/src/master/decode.scm
>
>
> It should probably be included in the guile src.
>
> Thanks,
>
> Joshua
>
> P.S.  I did not create that file.  I just found it elsewhere.

Thanks for that code, it can be quite useful!

I am trying to create some examples for web development currently.
Perhaps I can get that far, that I decode byte vectors in query
parameter values.

-- 
repositories: https://notabug.org/ZelphirKaltstahl

Re: Web development

[Ricardo Wurmus]

Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> writes:

> On 05.09.20 08:15, Joshua Branson via General Guile related discussions
> wrote:
>> You will probably want to borrow this code about how to decode byte
>> vectors in case you ever need to do any processing of POST requests:
>>
>> https://notabug.org/jbranso/autoassign/src/master/decode.scm
>>
>>
>> It should probably be included in the guile src.
>>
>> Thanks,
>>
>> Joshua
>>
>> P.S.  I did not create that file.  I just found it elsewhere.
>
> Thanks for that code, it can be quite useful!
>
> I am trying to create some examples for web development currently.
> Perhaps I can get that far, that I decode byte vectors in query
> parameter values.

Also see https://notabug.org/cwebber/guile-webutils/

-- 
Ricardo

mailman web interface (was: Diversification)

[pelzflorian (Florian Pelz)]

On Wed, Oct 23, 2019 at 02:33:43PM +0200, pelzflorian (Florian Pelz) wrote:
> If there isn’t one already, then I would like to start working on a
> written in Guile, free software, old-school bulletin board-like
> interface, perhaps with a more modern UI design, next week.  I do not
> like Discourse and will need something like this anyway for other
> projects.  I see there already is guile-email and Mumi.  So far I had
> no time looking at either.  I would start next week.
> 

I have rented a domain mailbaby.de (I hope the name is fine) and am in
the process of writing a Guix mailman 2 service, so we can move the
discussion on a new mailman web interface there.  Will report back
when it’s done.

Regards,
Florian

Re: mailman web interface (was: Diversification)

[pelzflorian (Florian Pelz)]

On Mon, Oct 28, 2019 at 12:04:36PM +0100, pelzflorian (Florian Pelz) wrote:
> On Wed, Oct 23, 2019 at 02:33:43PM +0200, pelzflorian (Florian Pelz) wrote:
> > If there isn’t one already, then I would like to start working on a
> > written in Guile, free software, old-school bulletin board-like
> > interface, perhaps with a more modern UI design, next week.  I do not
> > like Discourse and will need something like this anyway for other
> > projects.  I see there already is guile-email and Mumi.  So far I had
> > no time looking at either.  I would start next week.
> > 
> 
> I have rented a domain mailbaby.de (I hope the name is fine) and am in
> the process of writing a Guix mailman 2 service, so we can move the
> discussion on a new mailman web interface there.  Will report back
> when it’s done.

I am sorry to say I will not have the time to do a mailman Web
interface.  I am sorry to disappoint you.

Regards,
Florian

Re: mailman web interface

[Joshua Branson via General Guile related discussions]

This certainly sounds like an awesome project...doesn't Drew Devault
have a similar functionality with his lists project?  I believe that one
can have an account on his git repo, and make commits via git and/or the
web interface.

-- 
Joshua Branson
Sent from Emacs and Gnus

Re: mailman web interface

[pelzflorian (Florian Pelz)]

On Sat, Sep 05, 2020 at 02:21:31AM -0400, Joshua Branson via General Guile related discussions wrote:
> This certainly sounds like an awesome project...doesn't Drew Devault
> have a similar functionality with his lists project?  I believe that one
> can have an account on his git repo, and make commits via git and/or the
> web interface.

<https://sr.ht/~sircmpwn/sourcehut/lists> at first glance looks nice
to use and its setup.py says it is AGPL licensed.  It does not appear
to be an interface to non-sr.ht projects’ mailing lists.  Actually I
think email is still the best way to write to mailing lists of the
current Internet, only a JavaScript-free Web interface for reading and
searching was a good idea, though I can’t do it and old mailman2
already allows Web-based reading.

Regards,
Florian

Re: mailman web interface

[Joshua Branson]

Ok.  Thanks for the response.  Maybe the admin guys at the FSF could
migrate all their stuff to sourcehut and use it's list.  People could
still use an email workflow, and others that perfer a web based one
could use that too.

--
Joshua Branson
Sent from Emacs and Gnus

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1414 bytes --]

On Wed, Oct 23, 2019 at 11:37:24AM +0100, Chris Vine wrote:
> "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> wrote:

[...]

> > I would prefer eventually having a forum/bulletin board-like Web
> > interface to mailing lists in Guile and until then stick to pure
> > mailing lists.
> 
> That's pretty much what discourse is - an attractive web interface to
> something like mailing lists, with the option to use a mail client
> interface as well as the web interface if you want.

I've some practical experience with Discourse and... I'd say it's
the other way around. Shiny GUI is the paradigm, mail is just a
let's-keep-those-old-goofs-happy afterthought.

If you're wired around mail, it's not enjoyable. Feels like
a second-class citizen to me.

This doesn't sound positive, I know -- but I think the "problem"
might lie at a deeper level and won't be solvable without deeper
analysis (instead of hacking together yet-another-forum).

Just watch the regular conflicts between top-posters and top-post
phobia on other mailing lists: those tensions are cultural, and
can't be addressed "just" by a tool. 

I'm not dismissing Todor's insighful initial post -- not in the
least! Actually I think he's very right. But perhaps we need
bridges between cultures and not just between tools. And that
takes deep thinking (and people instead of machines, maybe).

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[Chris Vine]

On Wed, 23 Oct 2019 15:43:26 +0200
<tomas@tuxteam.de> wrote:
> On Wed, Oct 23, 2019 at 11:37:24AM +0100, Chris Vine wrote:
> > "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> wrote:
> 
> [...]
> 
> > > I would prefer eventually having a forum/bulletin board-like Web
> > > interface to mailing lists in Guile and until then stick to pure
> > > mailing lists.
> > 
> > That's pretty much what discourse is - an attractive web interface to
> > something like mailing lists, with the option to use a mail client
> > interface as well as the web interface if you want.
> 
> I've some practical experience with Discourse and... I'd say it's
> the other way around. Shiny GUI is the paradigm, mail is just a
> let's-keep-those-old-goofs-happy afterthought.
> 
> If you're wired around mail, it's not enjoyable. Feels like
> a second-class citizen to me.
> 
> This doesn't sound positive, I know -- but I think the "problem"
> might lie at a deeper level and won't be solvable without deeper
> analysis (instead of hacking together yet-another-forum).

I think I have an in-built resistance to getting excited about the
format according to which someone's public text message is transferred
and/or displayed to me.  Using the expression "message list" as a
generic term, I use message lists which use mailman and message lists
which use discourse.  I still use usenet for some things.  All of these
seem OK and keep me happy.

There is only so much you can do right or wrong with such things.  I
certainly wouldn't be spending my time rewriting them.

If you want private mailing lists with privacy, verification and
encryption, then that's another kettle of fish.  There's plenty of room
for new thinking there for sure.

Mailman web interface [was: Re: Diversification]

[pelzflorian (Florian Pelz)]

I believe mailman 2 as used on lists.gnu.org is the backend we care
about here.  I would prefer it if the mailing list Web frontend would
work as a MUA producing messages that look good in plain text,
monospace e-mail clients.  The MBOX from selected GNU mailman lists
would be the “forum” threads prominently displayed; other mail would
be private messages.  Should every user be given a
@guile-forum.gnu.org mail address?

Regards,
Florian

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[pelzflorian (Florian Pelz)]

On Wed, Oct 23, 2019 at 03:43:26PM +0200, tomas@tuxteam.de wrote:
> But perhaps we need
> bridges between cultures and not just between tools. And that
> takes deep thinking (and people instead of machines, maybe).
> 

I believe good mailing list etiquette is similar to good forum
etiquette.  Today’s culture is not a forum culture, of course.

Regards,
Florian

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1712 bytes --]

On Wed, Oct 23, 2019 at 10:02:11PM +0200, pelzflorian (Florian Pelz) wrote:
> On Wed, Oct 23, 2019 at 03:43:26PM +0200, tomas@tuxteam.de wrote:
> > But perhaps we need
> > bridges between cultures and not just between tools. And that
> > takes deep thinking (and people instead of machines, maybe).
> > 
> 
> I believe good mailing list etiquette is similar to good forum
> etiquette.  Today’s culture is not a forum culture, of course.

I'm talking of a more implicit culture.

I've taken part in more than one of those "split medium" situations,
the most common that one where the whole company had Outlook as their
UI whereas I had mutt. Issues like "top posting" were typical (top
posting being confusing for me, in-quote posting for most of the
rest of the world) and many other such subtleties.

If someone tries to explain something to someone else about one
of the exchanged messages, it is often in terms of the GUI. You
only become aware of that when you try to live at the rift.

Think "semantic markup" (which doesn't really exist). People think
in terms of "bold", "italic", "top left" etc, because that's how
they /read/ -- those markup's "semantic" varies just so slightly
depending on context. Then academicians come and say "no, no,
you have to think "semantically", i.e. in terms of "strong",
"emphasised", "important", etc -- and they are right, but then
they're not, because they are just peeling the onion off its
999th skin. When they finish, there's no onion :-)

At the end, the medium is (at least part of) the message, to steal
a well-known word.

Sorry for the rambling -- I hope you understand now what I
meant by "culture".

Cheers
-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[pelzflorian (Florian Pelz)]

On Sat, Oct 26, 2019 at 10:14:22AM +0200, tomas@tuxteam.de wrote:
> If someone tries to explain something to someone else about one
> of the exchanged messages, it is often in terms of the GUI. You
> only become aware of that when you try to live at the rift.
> 

Yes, this is something we should keep in mind.  IMHO the medium should
remain a mailing list and this should be clear.  Top posting is
useless and undesirable with both e-mail and forums though, I believe.

Since I use mutt too, I think plain text compatibility is important.

As for the formatting, I think for plain text e-mail compatibility,
when there are stars around a word, it should *not* be highlighted as
italic.

Regards,
Florian

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]

On Sat, Oct 26, 2019 at 11:03:12AM +0200, pelzflorian (Florian Pelz) wrote:
> On Sat, Oct 26, 2019 at 10:14:22AM +0200, tomas@tuxteam.de wrote:

[...]

> > only become aware of that when you try to live at the rift.
> 
> Yes, this is something we should keep in mind.  IMHO the medium should
> remain a mailing list and this should be clear.  Top posting is
> useless and undesirable with both e-mail and forums though, I believe.
> 
> Since I use mutt too, I think plain text compatibility is important.

See? There lies the problem. I'm firmly in your "camp", and still I
learnt to realise that the other "cultures" do have as difficult a
time to adapt to "our" camp as the other way around.

That's why I believe that we need serious thinking (beyond the "easy"
technical things) and lots of tolerance.

To me, Wikipedia is a wonderful inspirational example for a web site
which succeds in bridging an astonishly broad swath of those "cultures"
(and still doesn't cover all of them, it has a distinct academic and
"liberal", in the broadest sense, "smell" to it).

> As for the formatting, I think for plain text e-mail compatibility,
> when there are stars around a word, it should *not* be highlighted as
> italic.

Uh -- isn't the star reserved for *strong*? ;-)

Cheers
-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[Zelphir Kaltstahl]

On 10/26/19 1:26 PM, tomas@tuxteam.de wrote:
> On Sat, Oct 26, 2019 at 11:03:12AM +0200, pelzflorian (Florian Pelz) wrote:
>> On Sat, Oct 26, 2019 at 10:14:22AM +0200, tomas@tuxteam.de wrote:
> [...]
>
>>> only become aware of that when you try to live at the rift.
>> Yes, this is something we should keep in mind.  IMHO the medium should
>> remain a mailing list and this should be clear.  Top posting is
>> useless and undesirable with both e-mail and forums though, I believe.
>>
>> Since I use mutt too, I think plain text compatibility is important.
> See? There lies the problem. I'm firmly in your "camp", and still I
> learnt to realise that the other "cultures" do have as difficult a
> time to adapt to "our" camp as the other way around.
>
> That's why I believe that we need serious thinking (beyond the "easy"
> technical things) and lots of tolerance.
>
> To me, Wikipedia is a wonderful inspirational example for a web site
> which succeds in bridging an astonishly broad swath of those "cultures"
> (and still doesn't cover all of them, it has a distinct academic and
> "liberal", in the broadest sense, "smell" to it).
>
>> As for the formatting, I think for plain text e-mail compatibility,
>> when there are stars around a word, it should *not* be highlighted as
>> italic.
> Uh -- isn't the star reserved for *strong*? ;-)
>
> Cheers
> -- tomás

Hi!

Well, I hope that such tolerance does not lead us to accept usage of
mini-uglyfied proprietary JavaScript or other bad things, just to please
people, who in the majority most likely …

(1) … would never consider switching away from _their_ medium of choice,
because most people use it, so it must be right
(2) … have never even thought about the consequences of their choice of
technology (examples here are the web engine monoculture threat and
human interaction via Whatsapp and FB messenger, Skype)

I just want to point that out. While I find it to be a good idea to be
open to alternatives, I do not find it acceptable to not stay true to
our principles as a community of free software developers.

I also often see a very heavy imbalance between the amount of thought
some people in the free software world have put into their choice of
technology and the amount of thought the mainstream user has put into
their choice (usually zero, besides an "Oh it works!" or "It does not
cost me money!"). So we should not give up our principles, in order to
win some people over, because then we are actually the ones "won over"
(or lost) to the proprietary non-free world. It would not be a
diversification, but a disintegration of our community.

That said, I am open to trying out any community communication
technology, that follows the principles of free software and is run in
an ethically acceptable way.

I am highly skeptical of discourse, because:

* https://www.discourse.org/ tries to load Google Analytics and
fontawesome, 2 tools to spy on users. They already do not seem to care
about privacy.
* It is very JavaScript heavy.
* In my experience slow and sluggish.
* WYSIWYG-Editor – These tend to not produce plain text well readable
documents. Just give me some simple editor, Markdown maybe, not mandatory.

That is, why I like the idea of having a good old (newly written in
Guile) forum software. I would like and welcome such a forum software,
because some of my best memories of community interaction happened in
such a good old forum with a great community. It is also a great
structured long term memory. Whether the "other cultures" would use it
is on a different sheet of paper.

One more thing we should very much look out for, when choosing some
technology or when making our own software is:

* Can we actually get all our content out of that software if needed?
Can we export it to some JSON or other useful format?

Otherwise we will lock ourselves in.

Best regards,

Zelphir

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[tomas]

[-- Attachment #1: Type: text/plain, Size: 696 bytes --]

On Sat, Oct 26, 2019 at 03:02:57PM +0200, Zelphir Kaltstahl wrote:
> Hi!

Hi :)

> Well, I hope that such tolerance does not lead us to accept usage of
> mini-uglyfied proprietary JavaScript or other bad things, just to please
> people, who in the majority most likely …

[...]

Lemme digest your long mail for a while. In the meantime just a
short answer:

 - from experience I acknowledge that the issue raised by
   Todor Kondić exists. The tools used for communications
   may pose a barrier to some;
 - I don't like barriers :-)
 - I think the problem is beyond a problem of "tools", and
   to make that plausible here

More on your post later.

Cheers
-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[pelzflorian (Florian Pelz)]

On Sat, Oct 26, 2019 at 03:02:57PM +0200, Zelphir Kaltstahl wrote:
> Whether the "other cultures" would use it
> is on a different sheet of paper.
>

Perhaps single-use should be simplified, so that if someone cares only
about asking one question, they need not register or not for the
entire list.  I am unsure though.  I wonder what moderation would look
like.

Regards,
Florian

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[pelzflorian (Florian Pelz)]

Another aspect is that many popular e-mail providers and applications
are problematic.  For example, I have experienced Microsoft’s e-mail
services reformatting e-mails sent via Microsoft.  This breaks code
sent by them in e-mail, even in text attachments.

Also, many e-mail providers are not using monospace fonts or otherwise
disrupt how others expect their e-mail look when received.

A mailing list web interface may help these users.

Regards,
Florian

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[pelzflorian (Florian Pelz)]

On Mon, Oct 28, 2019 at 04:24:07PM +0100, Ricardo Wurmus wrote:
> Hi Florian,
> 
> > A mailing list web interface may help these users.
> 
> I probably missed something in this discussion, but here goes: have you
> looked at Mailman 3 and its web interface?
> 
> Here’s a demo:
> 
>     https://lists.fedoraproject.org/archives/
> 
> I think that’s really forum-like.  For some reason this newer version of
> Mailman is not in use within the GNU project.  (I’m guessing that’s due
> to a lack of GNU volunteers who could spare the time to upgrade while
> making sure nothing breaks.)
> 
> Is there something missing from Mailman 3 that your new project would
> provide?  I’m all for writing things in Guile, but I don’t see the
> urgent need for a mailing list web interface when there is Mailman.
> 

I frankly had never tried Hyperkitty yet.  It looks really good and is
very forum-like.  However, it also fundamentally relies on Javascript
and I would prefer browsing the archives without Javascript.  I will
look at it later and think some more.  Thank you!

Regards,
Florian

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[tomas]

[-- Attachment #1: Type: text/plain, Size: 687 bytes --]

On Wed, Oct 23, 2019 at 08:48:13AM +0200, pelzflorian (Florian Pelz) wrote:
> On Wed, Oct 23, 2019 at 08:16:34AM +0200, Amirouche Boubekki wrote:
> > Regarding the mailling list, many projects (among GNOME) have or will
> > adopt https://www.discourse.org/ [...]

> I only know that subscribing to GNOME Discourse required Javascript
> and its mail headers are less pretty compared to mailman.

Yep. That's another antipattern. The platform dictates the client,
the protocol is whatever the client /du jour/ which you download
time and again happens to talk today to the server.

With Discourse, at least, there's a mail interface, although I
perceive it as less-than-nice.

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[pelzflorian (Florian Pelz)]

It is nice to read what you write about successful use of Guile.

On Sun, Oct 20, 2019 at 06:10:45AM +0000, Todor Kondić wrote:
> But, I doubt any of them would find it natural to take a step
> further and participate in GNU itself (ugh, now I sound like a
> preacher of a new age religion). To my knowledge, interaction within
> GNU communities is still mostly mailing lists and IRC. This _not_ my
> students' natural digital habitat. I am probably not saying anything
> new, though ...
> 
> 

In my experience an e-mail account is still something everyone has and
which friends of mine use at their jobs.  I do not think this is a big
obstacle.  I believe all other on-line communication media have bigger
issues.  I would not like this to change currently.

Anyway, it is good if people know about Scheme and Guix because IMHO
the concepts they stand for are right and most important, even though
in (only) some aspects contributions are still desperately needed for
Scheme/Guile to catch up with other frameworks.  Diversity not only
fits the mission of the GNU Project, GNU also needs people.  But of
course others need people too and non-GNU or non-Scheme projects are
not always wrong.

Regards,
Florian

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[pelzflorian (Florian Pelz)]

P.S. I still believe professional use of Guile is in general a good
and effective way to diversify.

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[Mark H Weaver]

Hi Todor,

Todor Kondić <tk.code@protonmail.com> writes:

> [...]  I've set up my workflows around Guix, git(lab)
> and a customised Emacs installation (instead of R Studio). My small
> team of science students (majority female, various cultural
> backgrounds), never previously exposed to a GNU system to such an
> extent, managed to get a handle on it quite impressively.
>
> But, I doubt any of them would find it natural to take a step further
> and participate in GNU itself (ugh, now I sound like a preacher of a
> new age religion). To my knowledge, interaction within GNU communities
> is still mostly mailing lists and IRC. This _not_ my students' natural
> digital habitat. I am probably not saying anything new, though ...

You raise an important issue.  If we can improve the situation without
causing other problems, I think we should.  I don't know of any modern
replacement for mailing lists that has the properties we need, but I
*do* think there's a very promising alternative for live chat: Matrix.
Amirouche mentioned it elsewhere in this thread.

  https://matrix.org/

Matrix is supported by a very large and diverse set of free clients,
from modern Web-based interfaces to simple text programs, multiple
Emacs-based clients, and several gateways to other protocols such as
IRC, so that old-timers can use their preferred IRC client if they
prefer.

  https://matrix.org/clients/

Incidentally, there was recently an internal GNU project discussion
about how to better communicate with one another, and Matrix was
identified as an option that would meet our requirements.

The client that would likely be most attractive for the younger
generation is Riot.im:

  https://about.riot.im/

What do you think?

    Thanks,
      Mark

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[Zelphir Kaltstahl]

Hi!

I just want to share my experience with Riot.

I have used it before. In fact, I used it to communicate with only one
person so far for reasons I will mention below. Today there was a
strange thing, when Riot showed an error and warned, that it could be a
replay attack. This is not the first time something happened. If you
remember, that some time ago everyone had to upgrade their Riot.IM
client, because someone had intruded in the server system (Iirc it was
someone, who worked there before and still had access somehow. It was
linked on Hackernews. Let's see if I can find it … Probably one of the
search results of: https://hn.algolia.com/?q=riot.im).

We would have to ask ourselves, whether Riot is sufficiently independent
too. I believe it depends on the master server being up and running. If
we could have our own, that would of course be better.

The reason however, why I have only ever used Riot with one person is,
surprise surprise, that most people are not willing to sacrifice the
tiniest bit of comfort, for enhanced security. This one person I used it
with tried to get 2 more people on board, who were even less tech-savy
and whom I did not have the chance of helping directly, to get things
set up and so we remained 1-on-1 on Riot.IM.

Let me explain further:

To verify another person's device, one has to exchange information via a
second trusted channel. That information is a sequence of icons being
shown. If they are the same, that the other person sends you via the
second trusted channel, you can reasonably assume, that the device you
are communicating with is under their control.

When it comes to the step of exchanging information about what icons are
displayed, most people will close the app and say "it's too
complicated", because they do not understand it ("Huh? How strange! Why
I have to do that? Are icons secure?") or do not want to do anything in
order to have security. They are not willing to invest as much as 5min
of effort, to have encrypted chat. What makes matters worse is, that
when you use Riot.IM in the browser, it might happen, that every time
you log in, the other person has to re-verify your device. Guess what
people will do when facing that workflow …

As much as I like Riot.IM, it did have its share of problems and does
bring in some required effort for setting up communication. I would
personally still like to use it, however, I very much doubt, that
someone, who is not willing to use a mailing list, is willing to get
Riot.IM set up and keep it running, while being aware of the security
implications of trusting devices of other people, adhering to a good
security aware workflow. And we are not even using GPG on the mailing
list a lot, so people don't even have to deal with Enigmail yet, to post
and read on the mailing list.

Maybe offering Riot.IM as an alternative would still make sense, just to
see how it goes, but don't bet on many people joining Riot.IM. I am
willing to try!

Best regards,

Zelphir


On 10/22/19 8:47 PM, Mark H Weaver wrote:
> Hi Todor,
>
> Todor Kondić <tk.code@protonmail.com> writes:
>
>> [...]  I've set up my workflows around Guix, git(lab)
>> and a customised Emacs installation (instead of R Studio). My small
>> team of science students (majority female, various cultural
>> backgrounds), never previously exposed to a GNU system to such an
>> extent, managed to get a handle on it quite impressively.
>>
>> But, I doubt any of them would find it natural to take a step further
>> and participate in GNU itself (ugh, now I sound like a preacher of a
>> new age religion). To my knowledge, interaction within GNU communities
>> is still mostly mailing lists and IRC. This _not_ my students' natural
>> digital habitat. I am probably not saying anything new, though ...
> You raise an important issue.  If we can improve the situation without
> causing other problems, I think we should.  I don't know of any modern
> replacement for mailing lists that has the properties we need, but I
> *do* think there's a very promising alternative for live chat: Matrix.
> Amirouche mentioned it elsewhere in this thread.
>
>   https://matrix.org/
>
> Matrix is supported by a very large and diverse set of free clients,
> from modern Web-based interfaces to simple text programs, multiple
> Emacs-based clients, and several gateways to other protocols such as
> IRC, so that old-timers can use their preferred IRC client if they
> prefer.
>
>   https://matrix.org/clients/
>
> Incidentally, there was recently an internal GNU project discussion
> about how to better communicate with one another, and Matrix was
> identified as an option that would meet our requirements.
>
> The client that would likely be most attractive for the younger
> generation is Riot.im:
>
>   https://about.riot.im/
>
> What do you think?
>
>     Thanks,
>       Mark
>

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 1508 bytes --]


Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> writes:
> To verify another person's device, one has to exchange information via a
> second trusted channel. That information is a sequence of icons being
> shown. If they are the same, that the other person sends you via the
> second trusted channel, you can reasonably assume, that the device you
> are communicating with is under their control.
>
> When it comes to the step of exchanging information about what icons are
> displayed, most people will close the app and say "it's too
> complicated", because they do not understand it ("Huh? How strange! Why
> I have to do that? Are icons secure?") or do not want to do anything in
> order to have security. They are not willing to invest as much as 5min

In Freenet we have the same problem. We once had someone start an app
that used tapping phones together to exchange references, but it did not
get developed further.

It nowadays lives under my account, but I don’t have the time to work on
it (or rather: other things have higher priority for me).

https://github.com/ArneBab/Icicle

Maybe someone can find a tool there to ease initial setup.

Also TOFU is something we desperately need more of. For example I
recently had two unrelated people writing to me by email and our
communication was encrypted automatically because they used enigmail
with autocrypt and pretty-easy-privacy.

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1076 bytes --]

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[Chris Vine]

On Tue, 22 Oct 2019 21:23:32 +0200
Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> wrote:
[snip]
> The reason however, why I have only ever used Riot with one person is,
> surprise surprise, that most people are not willing to sacrifice the
> tiniest bit of comfort, for enhanced security. This one person I used it
> with tried to get 2 more people on board, who were even less tech-savy
> and whom I did not have the chance of helping directly, to get things
> set up and so we remained 1-on-1 on Riot.IM.
>
> Let me explain further:
> 
> To verify another person's device, one has to exchange information via a
> second trusted channel. That information is a sequence of icons being
> shown. If they are the same, that the other person sends you via the
> second trusted channel, you can reasonably assume, that the device you
> are communicating with is under their control.
> 
> When it comes to the step of exchanging information about what icons are
> displayed, most people will close the app and say "it's too
> complicated", because they do not understand it ("Huh? How strange! Why
> I have to do that? Are icons secure?") or do not want to do anything in
> order to have security. They are not willing to invest as much as 5min
> of effort, to have encrypted chat. What makes matters worse is, that
> when you use Riot.IM in the browser, it might happen, that every time
> you log in, the other person has to re-verify your device. Guess what
> people will do when facing that workflow …

This is a public mailing list, and any replacement of it is going to be
a mailing-list-alike.  Why do they (or chats) need to be encrypted or
have the sender verified?  No one should be posting sensitive personal
information here so I don't understand the point of it.  Lack of
understanding of (or disagreement with) the purpose may be what is
holding your idea back. If you want to set up private mailing lists or
chat servers, fair enough, but that's not what this is.

Discord seems a reasonably popular chat medium with a bridge to IRC and
discourse seems reasonably popular as a web based mailing-list-ish
medium with a somewhat more vibey feel than traditional mailing lists.

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[Zelphir Kaltstahl]

On 10/23/19 1:24 AM, Chris Vine wrote:
> On Tue, 22 Oct 2019 21:23:32 +0200
> Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> wrote:
> [snip]
>> The reason however, why I have only ever used Riot with one person is,
>> surprise surprise, that most people are not willing to sacrifice the
>> tiniest bit of comfort, for enhanced security. This one person I used it
>> with tried to get 2 more people on board, who were even less tech-savy
>> and whom I did not have the chance of helping directly, to get things
>> set up and so we remained 1-on-1 on Riot.IM.
>>
>> Let me explain further:
>>
>> To verify another person's device, one has to exchange information via a
>> second trusted channel. That information is a sequence of icons being
>> shown. If they are the same, that the other person sends you via the
>> second trusted channel, you can reasonably assume, that the device you
>> are communicating with is under their control.
>>
>> When it comes to the step of exchanging information about what icons are
>> displayed, most people will close the app and say "it's too
>> complicated", because they do not understand it ("Huh? How strange! Why
>> I have to do that? Are icons secure?") or do not want to do anything in
>> order to have security. They are not willing to invest as much as 5min
>> of effort, to have encrypted chat. What makes matters worse is, that
>> when you use Riot.IM in the browser, it might happen, that every time
>> you log in, the other person has to re-verify your device. Guess what
>> people will do when facing that workflow …
> This is a public mailing list, and any replacement of it is going to be
> a mailing-list-alike.  Why do they (or chats) need to be encrypted or
> have the sender verified?  No one should be posting sensitive personal
> information here so I don't understand the point of it.  Lack of
> understanding of (or disagreement with) the purpose may be what is
> holding your idea back. If you want to set up private mailing lists or
> chat servers, fair enough, but that's not what this is.
>
> Discord seems a reasonably popular chat medium with a bridge to IRC and
> discourse seems reasonably popular as a web based mailing-list-ish
> medium with a somewhat more vibey feel than traditional mailing lists.
>
Hi!

My example was about private conversation and a friend. So you are
right, that the example does not quite match the mailing list example.
Maybe we should clear up the question what kind of communication would
happen over such a new channel first, before making any decisions.

In Riot you will notice, that you see warning, when the devices are not
verified. That confuses users. Not sure what you can do about it in
terms of making settings default, as I have not used Riot in a public
communication scenario.

You did not address the other point I raised though: Dependency on a
third party server (and all the implications, when/if it gets hacked
again). Same goes for Discord. It would not be under our control whether
the server is running. In case of Discord: While we only need a mail
client for posting on a mailing list, using Discord requires to use a
bloated Electron app. When you start Discord and log in, the first thing
that happens is, that your CPU fan starts rotating, because of Discord
showing ads with videos. Do we really want to let people go through this
to interact with the rest of us?

There is also the problem of non-searchable content. You cannot, as far
as I know, search in a search engine through Discord or Riot messages.
If content by tendency of "quickly solving the problem in chat" moves to
non-searchable medium, it will mean, that searching in search engines
does not benefit from those solutions.

Another problem are the company policies of Discord. Not exactly a place
where you'd expect free software to happen.

However, like I said, I personally would be willing to try it, for sure!
Some communities already actively use Discord (Pharo community for example).

Best regards,

Zelphir

Re: Diversification [ branched from Re: conflicts in the gnu project now affect guile]

[pelzflorian (Florian Pelz)]

On Wed, Oct 23, 2019 at 02:57:03AM +0200, Zelphir Kaltstahl wrote:
> You did not address the other point I raised though: Dependency on a
> third party server (and all the implications, when/if it gets hacked
> again).

A matrix server and its coordination server could be hosted by anyone;
AFAIK it is simple HTTP.  Most projects would not host the
coordination server themselves though.

I do not know the legal implications from offering encrypted, private
communications which would AFAIK be offered implicitly when using
Matrix even though we do not need it.  It may be legally preferrable
to have a serverless communications medium that need not be hosted,
Gnunet-style (not to mention that supporting another GNU project fits
well).  My outdated impression is that the Gnunet project is far from
offering popular messaging apps though.

Additionally, few people have real security.  Most people download
software from all over the internets and run it.  At the very least,
people's operating system provider could be forced by law or by
crackers to push a trojan via update.  Claiming more security than
what can be offered seems dishonest.

> There is also the problem of non-searchable content. You cannot, as far
> as I know, search in a search engine through Discord or Riot messages.
> If content by tendency of "quickly solving the problem in chat" moves to
> non-searchable medium, it will mean, that searching in search engines
> does not benefit from those solutions.
>

There should be searchable logs.  I am confident searchable logs can
be implemented for Matrix like they can with IRC.

Matrix may be a step forward from IRC or it may not matter at all.
I do not know as I am not using synchronous communication personally.

Regards,
Florian