"Install this app" doesn't say which app

[mkj]

I visit https://alpha.sandstorm.io/install/4e1da8cec67250de8fa80371bc21f4eb?url=http://sandstorm.io/apps/ipython-notebook.spk and it says

Install this app? Do you want to install this app?

[button]Install[/button]

But the only indication of the App's name is in the URL.

[kaos]

+1, was also thinking of reporting it, but wasn't bothered enough at the time (too much else to explore ;)

[kentonv]

Yep, this is something I want to improve eventually, just hasn't come to the top of the priority queue yet.

An interesting question is how to deal with the possibility of apps lying about their identity, possibly to trick people into installing an impostor app. For apps in the app list (or eventual app store) we can do some manual policing of this, but for unreviewed side-loaded apps what can we do? It may be best to keep the current flow, annoying as it is, when installing an app that has not been manually verified. (Though we also have to deal with a similar problem when it comes to naming the "New X" actions installed by the app.)

[ocdtrekkie]

My largest concern, of course, is that attempts to ensure the legitimacy of apps' identities can result in a desire to create a more locked down system. For an app store, obviously, any app where the identity of the author is key, you need some form of verified check mark. (It was apparent to me that neither bank I do business with has any sort of market near their name on the Play Store confirming the app I'm putting my account details into is actually from my bank.)

For the server itself, your best bet is to tell people to ensure they are following a link from the author's own website to be certain. Providing hashes of the SPKs is probably a must.

Maybe the app store could broadcast out a list of trusted SPKs and their hashes for verified authors, and the Sandstorm server could allow you to add lists of trusted apps from any authority provider, and specify whether or not it would allow, block, or warn on attempts to install untrusted apps? Including the server administrator's ability to add to their own trusted list, as they verify apps themselves.

[kentonv]

The install link contains a hash, so it's impossible to get an app other than the one the referrer page intended.

I think the solution here might end up involving the (hypothetical) app store. When installing an app that is known by the app store, we could pull metadata from it and display that. The app store would be moderated, which will prevent most spoofing attacks.

When sideloading, I think it may be best to continue not displaying a title at all. If we display a title that comes from the package, we would need to display some fine print explaining that the title is only what the package claims. No one would read that fine print. But if we don't display the title at all, then I think people are more likely to intuitively realize that the referrer could have linked them to anything, and they should only proceed if they think the referrer is trustworthy.

Of course, at present we then go ahead and accept the "new document" actions using whatever text the package provides. Perhaps we need to think of a better solution there. One thing that comes to mind is that if we don't have a verified title for an app, we could force the user to name the app themselves. We could then change the "new document" actions to always be of the form "New [app name] [noun]", where only "[noun]" is provided by the package. Would that be too annoying? Keeping in mind that the app store will eventually be the usual way to install apps, and sideloading is more of a power-user thing, maybe it's OK?

Thoughts?

[ocdtrekkie]

My notion of offering the list of hashes or something to that effect is that you could "sideload" apps that could still have their identity verified by the app store, if they're the same. I think whatever you do down this avenue it'd be preferable if it remain possible for a third party app store or internal service to provide the same assurances.

I'd definitely rather display a title than not, though a nice exclamation icon should clearly denote that it isn't necessarily trusted.

[ocdtrekkie]

I suppose in the short term though, you could just have a quick check that the app is coming from sandstorm.io/apps and otherwise, display the untrusted warning next to the app name.

[kentonv]

My notion of offering the list of hashes or something to that effect is that you could "sideload" apps that could still have their identity verified by the app store, if they're the same.

Right. I think when we queried the app store database, we'd pass the app ID, which is the same for all versions of the same app. The app ID is also the public key used to sign an app package. So this would let you sideload a different version of the app than is available in the app store and still get a title.

As far as third-party app stores are concerned, I think it may make sense to allow users to specify other app stores that they trust, that implement the same API. Aside from competition, I want to support companies that use Sandstorm internally having an "internal app store" to help employees get the right stuff installed. Though, it may turn out that this only makes practical sense at the host level rather than per-user.

[kentonv]

I suppose in the short term though, you could just have a quick check that the app is coming from sandstorm.io/apps and otherwise, display the untrusted warning next to the app name.

That's harder than it sounds because the server doesn't actually download the URL if it already has an app matching the hash. So if you know the app you want is already on the target server you can provide any URL and it will succeed. This actually may be a problem in itself, in that some users might infer some trust based on the URL parameter... maybe we should actually automatically hide it from the address bar once the download completes.

[ocdtrekkie]

Aside from competition, I want to support companies that use Sandstorm internally having an . "internal app store" to help employees get the right stuff installed. Though, it may turn out that this only makes practical sense at the host level rather than per-user.

To me, it makes sense that approving trusted app stores be on a server admin level, not a user level. Given that a trusted/untrusted warning is generally to advise the user where they may not be fully equipped to judge that trust themselves.

[ocdtrekkie]

Also, of course, because in a corporate setting, a server admin might also expect the option to disable installation of untrusted apps. (Combined with the capability to run their own basic internal 'app store', this would amount to an app whitelist, effectively.)

[kentonv]

Indeed, although, if Sandstorm is doing its job right, there should be no need to limit what employees can install.

[ocdtrekkie]

Sure, but some companies block Facebook. It's not just a security feature. ;) Companies may not want people loading up streaming music libraries on their corporate servers, whereas they don't mind development tools with similar resource constraints.

And we never want to assume the software will always be doing it's job right. If some sort of zero-day exploit is found, it'd make sense to disable untrusted installs until one's server is patched.

[dckc]

Seaborne wrote a paper about petnames/icons for apps, no? I'll see if I can find it.

[dckc]

In CapDesk, at application installation time the application proposes a pet text and a pet graphic (the icon for the top left corner, and the text in the title bar that is immediately adjacent). The user may accept this petname or modify it. Windows launched thereafter by the installed application are unforgeably marked with the petname. Limited informal experimentation suggested that the CapDesk petname system was intuitive and easy to use, like the buddy lists.

-- An Introduction to Petname Systems by Marc Stiegler, Feb 2005, copyright under the MIT X License updated June 2010

[kentonv]

Sandstorm takes many ideas from Capdesk, especially the Powerbox. I am, however, far less confident than Stiegler that users would ever modify a proposed petname, even when it is actually maliciously impersonating another app. I think that users have a hard time understanding the provenance of information presented to them. I also think it's a terrible user experience to make them choose an icon, since that's much harder to make up than a name.

So I'd prefer only to present a name/icon at all if we have some confidence in its accuracy, otherwise require the user to supply the name (and use no icon, or a generic icon).

[dckc]

OK. Then it's not clear to me...

• why sandstorm asks you "install this app"? after you already asked it to do that; i.e. what authorization the user is granting after verification
• what verification actually verifies and why. (It seems to just enable app updates, but maybe there's more to it.)

Here's hoping for time to pore over the docs and source. Any pointers would be appreciated.

[kentonv]

why sandstorm asks you "install this app"? after you already asked it to do that; i.e. what authorization the user is granting after verification

We actually skip this step if the referrer is sandstorm.io/apps. The problem is that, by design, other sites are allowed to present you with install links as well, and a site could trick you into clicking that link when you didn't really want it.

The reason you are seeing the confirmation even when installing from sandstorm.io/apps is because you are accessing your server over HTTP rather than HTTPS, but sandstorm.io is HTTPS-only, so the referrer URL is dropped when clicking through.

Eventually we will find a better way to handle this than through the referrer header.

what verification actually verifies and why. (It seems to just enable app updates, but maybe there's more to it.)

"Verification" here means that a trusted human curator has checked this app's title and icon and verified that they are not trying to impersonate another app.

Here's hoping for time to pore over the docs and source. Any pointers would be appreciated.

A lot of what we're talking about here is speculative, not stuff we've implemented yet. There is no app store yet, for example.

[dckc]

The reason you are seeing the confirmation even when installing from sandstorm.io/apps is because you are accessing your server over HTTP rather than HTTPS, but sandstorm.io is HTTPS-only, so the referrer URL is dropped when clicking through.

Ah yes... from the alpha, I don't get his page at all.

And app installation is fast. I guess that's because they're already downloaded?

[kentonv]

And app installation is fast. I guess that's because they're already downloaded?

Yes. :) If someone else already installed the app (matched by hash of the package) then "installing" it for you is basically just flipping a bit.

[rds13]

Having just install my first application I do find it surprising to not see any application name on that step. I was about to fill a bug report for that too. I've read all the comments and still I think there should be an application name displayed. It could simply be shown between quotes with an unverified badge as long as we cannot provide a workflow for trusted applications.

[glamrock]

I was just noticing this as well. The intermediate fix could be as simple as a &app= flag in the referring url.

[kentonv]

We do actually have metadata for this in the package now. I suppose we should go ahead and display the name from there, and once the app store is up we can start doing actual verification of names.