Well, that was disappointing...

[Nolan Darilek]

Our co-op's Sandstorm transition lasted about 18 hours. :( Here are the
issues people encountered. Note that I don't know that there's any way
for Sandstorm to address these, I'm just providing them for
completeness' sake.


We have a wiki running at http://lareunioncoop.org. I replaced this with
a static WordPress site linking to a public, read-only share of the wiki
hosted in Sandstorm. Users were frustrated that links no longer worked,
so what is now at http://lareunioncoop.org/meetings couldn't continue at
that link if hosted in Sandstorm. I wonder if there might be some way in
the future to make sharing links full domains, so
https://wiki.lareunioncoop.org might somehow have redirected to the less
user-friendly Sandstorm share link. Don't replace them entirely, just
add some mechanism for attaching them to subdomains somehow.


Also, here's a bit of feedback posted to our internal list. Again, not
sure what might be done about it, just posting it as an example of the
resistance I've encountered:


Overall imo this seems more like an internal "back end" solution.
I.E. this seems like another tool we could use like the email list, or
celly of yesteryear, or trello, or as some have proposed a co-op slack
instance.

It does not seem that great for "front end" purposes
i.e. what we show the general public.

The links alone tbh make our site look untrustworthy and like I'm going
to get a virus (to the ignorant).
Not to mention my security addons cause the site to freak out meaning I
have to disable them (I fuckin hate frames that need specific referral
links, personal problem I know)..

Just seems like a bit of extra overhead for serving the front page that
we don't need. I really don't see the point in creating a static landing
page with a sidebar to link to another different static landing page
with a different sidebar. The fact that by the time you get to the wiki
you've gone through 3 different UI's is needlessly confusing.

[Nolan Darilek]

Just a bit of brainstorming--I wonder if the login step for clicking on
public sharing links might be streamlined somehow? I can see how it
might be confusing/worrisome to be asked to log in when clicking what
you believed to be a public link. Maybe the page gets served up
anonymously by default, with some indication that you can log in for
greater privileges?

[Ian Denhardt]

Quoting Nolan Darilek (2016-08-23 13:51:18)

> Overall imo this seems more like an internal "back end" solution.
> I.E. this seems like another tool we could use like the email list, or
> celly of yesteryear, or trello, or as some have proposed a co-op slack
> instance.
>
> It does not seem that great for "front end" purposes
> i.e. what we show the general public.
>
> The links alone tbh make our site look untrustworthy and like I'm going
> to get a virus (to the ignorant).
> Not to mention my security addons cause the site to freak out meaning I
> have to disable them (I fuckin hate frames that need specific referral
> links, personal problem I know)..

This.

This is a good summary of 90% of where Sandstorm lets me down. I
basically can't use it for anything the internet is supposed to see. The
static publishing thing is (1) a hack, (2) limited in what it can be
used for and (3) in most cases more effort than just setting up nginx.

I would like to be able to use sandstorm for things (besides static
pages) that are presentable to the public internet.

Related issue on github:

https://github.com/sandstorm-io/sandstorm/issues/1680

I know this has been brought up before, so I won't harp on the point
too much here. But yeah, that's a pain right now.

[Nolan Darilek]

Sorry if this is getting noisy--I'm just disappointed that Sandstorm
didn't work out in what I'd expected to be a slam dunk case, and am
trying to understand/empathize with concerns.


I did try accessing our meant-for-the-public, read-only wiki link. Our
wiki is pretty dynamic, so wouldn't make sense (and would be difficult)
to render statically. It is a bit odd when logging in to indicate that I
want to browse anonymously. I get the security arguments, but I might
also be put off if someone said "hey, check this co-op out, they have
all their policies on a wiki," and the first thing I saw was something
encouraging me to pick how I browsed it. I seem to recall changes that
encouraged visitors to sign in a while back. I'm wondering if this is
how those changes manifested, and if so, if they might be undone? It
might sometimes be appropriate to nudge visitors to sign in, but it
might also be appropriate to tacitly respect whatever context they
present to you, be that signed in on the server or browsing anonymously.
For an app that conveys clear benefits when signing in, nudge users in
that direction. But for a public wiki that needs some dynamicity, most
of our *own* users don't even sign in during much of their use.


Thanks.

[Nolan Darilek]

To be clear, this quoted bit was written by one of our members, not by me.


I think his iframe concerns would probably fade with time. As I pointed
out in response, our current non-Sandstorm setup has a variety of *real*
security issues without someone imagining that others exist just because
Sandstorm uses an iframe. :) That said, I can empathize with concerns
around being asked how to access a resource that needs to be just a bit
dynamic. I think our average visitor is going to wonder why they're
being asked that, and if they aren't actually members who know me, they
may just go away.

[Asheesh Laroia]

Hi Nolan!

This is pretty interesting feedback, and I'm glad you're sharing it! I'm not literally have fun reading the feedback because it's a little saddening, but it's a set of sad truths that, once we hear them, we can consider doing something about. So please do continue sharing, and feel free to be as noisy as you want.

I should also start by saying that running public-facing web apps isn't our focus for the next few months, or maybe even longer. We really want to solidly implement all the needed features for the productivity-suite-type use-case first.

I was hoping that static publishing might work for y'all's needs, but it seems it might not. Having said that, one possibility might be for the wiki to have a "Log in to edit" button in the top-right, and this would take you to the grain URL and you'd deal with login there. Still, it'd be strange that the URL in the address bar is different based on static publishing vs. when you're logged in.

As for this:

> I did try accessing our meant-for-the-public, read-only wiki link. Our wiki is pretty dynamic, so wouldn't make sense (and would be difficult) to render statically. It is a bit odd when logging in to indicate that I want to browse anonymously. 

I think you're referring to (what I'll call) the identity interstitial. Namely, before you see the grain, you choose which "identity card" you want the grain to know you as.

I believe users only see the identity interstitial if they are currently logged-in. You wrote:

> I seem to recall changes that encouraged visitors to sign in a while back. I'm wondering if this is how those changes manifested, and if so, if they might be undone?

To clarify, the way we encourage visitors to sign in is by showing a "Sign in so that collaborators know who you are" drop-down in the top-right. You can see that if you visit this link incognito: https://oasis.sandstorm.io/shared/NuLk-CtkFeGj5iwyAGOIQuzwV3NdvpnSngXlxavnAZu .

The identity interstitial is only shown to users currently logged in to this Sandstorm server.

I just wanted to repeat that since the identity interstitial is a separate thing from the "Sign in so your collaborators know who you are" drop-down.

You wrote:

> Just a bit of brainstorming--I wonder if the login step for clicking on public sharing links might be streamlined somehow? I can see how it might be confusing/worrisome to be asked to log in when clicking what you believed to be a public link. Maybe the page gets served up anonymously by default, with some indication that you can log in for greater privileges?

One thing we could do is allow the creation of special sharing links that remove the suggestion to log in from the top-right. David, I'm curious for your thoughts on that whenever you have time to share them.

Do keep in mind that this "identity interstitial" is only visible for people who choose to log in to Sandstorm. However, I do suppose that most people think they're "logging into the wiki"; see below.

>  It is a bit odd when logging in to indicate that I want to browse anonymously.

This is interesting. It sounds like you're referring to this flow:

- Visit a sharing link while not logged-in

- Log in successfully

- Be asked if you want to share this identity with the grain, or alternatively stay anonymous

It seems to me that we should skip step 3. If you're signing in while looking at a grain, we should share that identity with the grain. David and others, curious for your thoughts about that.

For this item:

> I wonder if there might be some way in the future to make sharing links full domains, so https://wiki.lareunioncoop.org might somehow have redirected to the less user-friendly Sandstorm share link. Don't replace them entirely, just add some mechanism for attaching them to subdomains somehow.

This is possible if you set up an nginx redirect, although admittedly that's a lot to ask! Setting up "short URLs" like this could become a Sandstorm feature, and honestly I would love it myself.

Let me know what you think of the above. Thanks for being so direct and for choosing to share all this feedback.

--
You received this message because you are subscribed to the Google Groups "Sandstorm Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sandstorm-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nolan Darilek]

I'm not sure which flow I triggered when logging into the public wiki sharing link. I recall being asked if I wanted to stay anonymous, and because it wasn't the "open in incognito mode" phrasing I see when opening grains from the main interface, I assumed it was something else. Perhaps the wording around that could be unified if it isn't already? Honestly I was just scrambling to get things functional and wasn't documenting my experience in detail.

I know we can set up Nginx rules, but I can't stress enough that I'm looking for something that's very much set-up-and-forget. One of my main criteria for choosing technology for the co-op is asking myself how it would endure months or years of neglect. If the answer is "it will keep working, behave sensibly when it crashes, and not acquire new security issues by virtue of auto-updates or something else" then I'm all over it. If there's a chance that something won't work because someone lost the password database despite being sent it several times, and the problem may not get fixed until it gets sent again and we meet up in person so I can deliver the master pw (yes, that was a thing) then the likelihood that I'll add it to our stack lessens slightly. I realize that's a tall order, which is why I'm trying hard to stick with Sandstorm exclusively, no fronting HTTP server with the added SSL configuration and rewrite rules.

I just realized I'd likely lose Sandcats-provided SSL if I used a proxy, since Nginx would need the certs and have to be restarted periodically whenever they changed.

To unsubscribe from this group and stop receiving emails from it, send an email to sandstorm-de...@googlegroups.com.

[Kevin Reid]

On Wed, Aug 24, 2016 at 8:49 AM, Nolan Darilek <no...@thewordnerd.info> wrote:

I know we can set up Nginx rules, but I can't stress enough that I'm looking for something that's very much set-up-and-forget. One of my main criteria for choosing technology for the co-op is asking myself how it would endure months or years of neglect. If the answer is "it will keep working, behave sensibly when it crashes, and not acquire new security issues by virtue of auto-updates or something else" then I'm all over it. If there's a chance that something won't work because someone lost the password database despite being sent it several times, and the problem may not get fixed until it gets sent again and we meet up in person so I can deliver the master pw (yes, that was a thing) then the likelihood that I'll add it to our stack lessens slightly. I realize that's a tall order, which is why I'm trying hard to stick with Sandstorm exclusively, no fronting HTTP server with the added SSL configuration and rewrite rules.

I read this and thought “What if a Sandstorm grain could be/manage your Nginx?" But I think that's not quite the best answer:

The reason Sandstorm static publishing has unfriendly URLs is because there's no mechanism to allocate the namespace 'fairly', right? But perhaps Sandstorm could eventually have an API allowing a grain to be given the authority to create non-random names (and in general arbitrary URLs under domains that are pointed at the Sandstorm server), and that grain would provide UI and policy to manage that on behalf of other apps like MediaWiki or WordPress.

[Kenton Varda]

Hi all,

We've been exploring ways to make "stand-alone grains" a reality.

There are some details in this document:

https://oasis.sandstorm.io/shared/8NmVVVf70-Nc1_nKQKGaopOI1JpyQSKhiynOoq9Co47

Summary:

- We'll make it possible to publish a grain to a custom domain, with no Sandstorm topbar/sidebar, but still being able to use Sandstorm trusted UI for login and powerbox. (Pretty much, it's still Sandstorm but with the topbar/sidebar "display:none".)

- HOWEVER, there is a security concern with publishing to user-controlled domains: the user could trivially set up a MITM proxy that could see / manipulate the trusted UI communications. Hence we can only publish to domains that the admin designates as trusted.

- We also have concerns about phishing if users are able to choose names that are subdomains or paths within, e.g., oasis.sandstorm.io. We should probably implement a way to specify a separate "user content" domain where users can grab whatever subdomain they want.

- We are initially focusing on improving the UX of our own feature key purchase UI, which we host on Sandstorm, which means that initially we may not expose this feature directly in the UI -- it may require some database poking.

I remain pretty worried that by making these features readily accessible, we may be encouraging apps to go back to monolithic rather than fine-grained design, defeating our security policy and much of the benefit of Sandstorm. So, I want to be very cautious about this.

-Kenton

--

[Mitar]

Hi!

On Tue, Aug 23, 2016 at 7:28 PM, Ian Denhardt <i...@zenhack.net> wrote:
> Related issue on github:
>
> https://github.com/sandstorm-io/sandstorm/issues/1680

In addition it has been brought up in the past as well:

https://github.com/sandstorm-io/sandstorm/issues/1845

By not just me, but also another collective
(http://omni-oakland.org/), who was also investigating using it for
their collective and decided not to so:

https://github.com/sandstorm-io/sandstorm/issues/1845#issuecomment-210691106

The issue was simply closed.

So this is not the first time Sandstorm "failed" in this regard.


Mitar

--
http://mitar.tnode.com/
https://twitter.com/mitar_m

[Nolan Darilek]

Thanks! This looks great, and I like what I'm seeing thus far!

I hear your worries re: negating some of Sandstorm's benefits by putting this in place. The counterpoint I'd offer is that, at the moment, our organization is running an unsandboxed PHP-based app on an HTTP URL. Yes, we would lose some of Sandstorm's functionality for *one* app we run with this change. Organizationally though, our switch to Sandstorm gets us *more* security for that one app, plus *full* security for anything else we run. It also transitions us to a self-hosting organization that can start owning our data, to which you can attach whatever value that might be worth to you. :) IOW, for those of us without lots of resources but wanting to own our own data and build our own systems, the value you add with this outweighs the abuse/misuse possibilities significantly. At least, that's my thinking as someone who would benefit directly and significantly from this.

And, FWIW, I'm likely to use this sparingly. But it has been made clear to me that folks don't want our wiki migrated to Sandstorm unless we can keep all our URLs. This change gives us a clear migration path, preserving what we have now in a more secure form while letting us build more in the future.

I'll start another thread for this, because there are things I'd like to see in the implementation if at all possible.

To unsubscribe from this group and stop receiving emails from it, send an email to sandstorm-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sandstorm-dev/CAOP%3D4wg_2g7qHx2Ft4UHanVJCdxbJnE%2B%3DZu%2B1MKfgmVj8a4xrA%40mail.gmail.com.

[Mitar]

Hi!

Nolan, would your users be OK installing a browser extension?

Because then it might be possible to have both normal public facing
content and editing through it, while keeping the security properties.
So without a browser extension all users could be just anonymous, and
if they have a browser extension they could use it as a signed-in
user.


Mitar

>> email to sandstorm-de...@googlegroups.com.

>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Sandstorm Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sandstorm-de...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sandstorm-dev/CAOP%3D4wg_2g7qHx2Ft4UHanVJCdxbJnE%2B%3DZu%2B1MKfgmVj8a4xrA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Sandstorm Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sandstorm-de...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/sandstorm-dev/8ca1caa1-f2b4-6ab8-e7fe-31e26b8901ff%40thewordnerd.info.

>
> For more options, visit https://groups.google.com/d/optout.



--

http://mitar.tnode.com/
https://twitter.com/mitar_m

[Nolan Darilek]

I doubt it. At that point, they could just deal with a URL change.
Sorry, not trying to be difficult, just noting that folks unwilling to
accept new URLs won't want to instead install an extension.