add full internet toggle to footer

[WardCunningham]

Our federation spans two protocols, http and https.

The full federation is only visible when the origin javascript comes from an http site. Some argue that a more restricted internet is preferable. We would argue that even when this is the case a user must be able to view the full internet if the attribution clause of the CC BY-SA 4.0 license is to be meaningful. This pull request elevates this decision to a check-off in the web page footer.

This implementation will sense the protocol in use and display a check mark accordingly.

We have not implemented the code that will change protocol but expect it will have a user experience similar to enabling or disabling wiki mode with the adjacent check-off.

We don't know if it is possible to dynamically detect what protocols are supported by a given server. Perhaps this will require a server configuration parameter. In any case we suggest when full internet is unavailable that clicking the full check-off should open an informative about-page explaining the potential violation of license terms.

[WardCunningham]

This pull request seeks a middle ground in the disagreement as to the value of having two protocols. Here I quote my disappointment that I could not read the ongoing conversation from a page I wrote. Here I quote matrix.

[paul90]

This doesn't appear to do anything other than add a tick mark that can be toggled.

The real problem is people deploying https only wiki. That problem can only be addressed by getting them to switch to supporting http in their installations, and not redirecting from http to https. And maybe adding an automatic redirect from https to http if the user is not the wiki owner - and subjecting people to endless redirection if a site refuses to allow http!

I would be reluctant to opening the proxy to all, as that risks creating an open proxy.

[Bortseb]

automatic redirect from https to http if the user is not the wiki owner

Where would this be done? A proxy, like traefix or caddy, could do this all on its own? or wiki-client is needed to determine the state of the user being logged in or not?

[paul90]

In reality that is not something that is likely to be workable.

Looking again at the original proposal:

'full' is not self explanatory - definitely needs a page to explain, probably use an antonym of open (maybe limited) and only show if accessed via https and not the owner.

A toggled tick does nothing, so remove. Maybe replace with a link to a wiki page explaining the limitations, but needs a link to open the lineup using http.

An additional approach maybe to provide hints to an author that the content they are reading will not be accessible to others, and to offer some real options for the reader when the edge of the limited island of federation is reached.

This may include giving pages accessed via the proxy a tint, and at the edge providing links to page that can't be reached, reloading the lineup over http, and maybe using a different origin.

[WardCunningham]

I regret that the user-interface that I suggested here did not include a workable integration with all https implementation mechanisms. This is not my strength.

[Bortseb]

The approach that I was most interested in was what I quoted from you. Is this the bit you are saying isn't workable? I wasn't thinking of adding interface buttons or explanations for what's going on, I was hoping to resolve the issue if possible.

I was wondering... Could a wiki be set up using passportjs (generic OAuth), and treafik or caddy, to only allow authentication over HTTPS, but redirect all visitors by default to HTTP if they aren't logged in (So the neighborhood and everything works)... but then as soon as the padlock is clicked, if on HTTP, then redirect to HTTPS for log in (since it would only be possible over HTTPS)

[WardCunningham]

I suggested the term "full" under the assumption that if the site was showing many sites to be unreachable they might switch on "full" and see if they became visible. Some sites support both protocols but require (as I understand) that the user knows how to edit the url location bar to select the less encumbered (full) internet.

This polarity, check for more, is consistent with the "wiki" link beside it. Check wiki to begin editing and understand that pages can be accidentally changed when edit is enabled.

[WardCunningham]

Maybe time to think about this usability short-cut again.

[paul90]

There are a number of factors in play here:

1. Browser vendors that think making it harder for end users to use http is a good thing. Didn't we briefly see access to http completely blocked for a brief period? How long until this becomes the norm?
2. Wiki that are https only.
3. Wiki that are http only.

All three had good reasons for their stance. But, Wiki Farm owners, by not supporting both http and https are throwing obstacles in a readers path.

Adding UI to try and side step does not make the user's life easier - just look at the number of times that the wiki tick has caused confusion.

As for the wording? That has previously been discussed. Probably more meaning full to put the current protocol there, as the browser vendor's now hide it!

The only way of addressing this issues, would be to move away of the browser, and in all probability also the http based server.

[paul90]

Oh, and lets not forget that Login to View, adds further complexity - especially when the login requires TLS, and in all probability makes the logged in session TLS only.