A number of apps redirect users to different origins from the origin submitted to app mining. (https://example.com is one origin, https://alice.example.com is a different origin). 
Blockstack's security model is origin-based - a different origin is a different app. It is important that users understand which app they are using and redirecting between multiple origins hurts that goal.

Proposal: App developers must submit the origin of the app they wish to review. Redirects to other origins will not be reviewed.

@larrysalibra about this issue, will you consider sharing auth between multiple apps? like x.app.com and y.app.com like what Microsoft or Google apps doing so users don't need to sing in every time. Or you consider this as this issue?

App publishers should submit

• a url for the landing page and
• the app domain.

I agree with @friedger on this one.

Especially with TryMyUI testing, the audience needs to have context of the application use case. Isn't this pretty standard practice of using the domain/subdomain?

Landing page is a separate repository a static page focused on SEO. App page is a separate repository specific for the app use case.

What do you think about...

If TryMyUI -- Direct them to the landing page If Nil -- Direct them to the app page

I agree with @friedger & @kkomaz's proposal as well.

the audience needs to have context of the application use case

This makes sense to me.

will you consider sharing auth between multiple apps? like x.app.com and y.app.com like what Microsoft or Google apps doing so users don't need to sing in every time. Or you consider this as this issue?

@Walterion1 I know redirects are common in the existing web, I believe this is bad for users because they enter a url thinking they're going to one place and interacting with one domain and then get redirected to some other place entirely outside of their control. Wanting to have two apps accessing the same data seems like a perfect use for collections.

I agree with @friedger & @kkomaz's proposal as well. I'm having second thoughts about this already.

Why can't you have marketing pages and other pages of an app on the same origin?

How you want to organize your development of the app doesn't seem necessarily connected to how it is presented to the user. It's not hard to do it all on one origin.

If a user a user visits example.com and is sold by that site on using the app and clicks the sign in button, they should sign in to example.com, not some other origin.

I think this makes more sense in a world where apps are distributed by blockstack names. With blockstack names, alice.example.id and example.id are not assumed to be controlled by the same party. The owner of example.id doesn't have any control over alice.example.id.

Yes, collections are on my waitlist. So you prefer a mobile app way, every app using the separate set of permissions. I like it, but today users are not a fan as we had some angry emails or even TMUI testers that said: "Why I should sign in again?" Maybe it needs a learning curve for users.

If a user a user visits example.com and is sold by that site on using the app and clicks the sign in button, they should sign in to example.com, not some other origin.

I think this is the issue of SSR vs. SPA. SPA is horrible for SEO but great for application development. SSR/Static is great for landing but can be either too simple or complex depending on the use case of your app. Thus the separation.

Maybe it could be helpful to just submit a link to the web manifest. The app domain can be deduced from that. (and it would help to reuse the information for theblockstats.com or app-center.openintents.org)

I suggest a dry run to see how many apps this affects and @larrysalibra can you please follow up with specific instructions for how you will test and score.

If an app redirects away from the submitted origin (excluding the redirect to the Blockstack Browser), we'll stop review and provide scores only based on the content and behavior at the submitted app origin.

Example:

App developer submits https://landing.example.com and clicking Sign in with Blockstack sends the user to https://app.example.com. Review will stop when the user navigates away from https://landing.example.com and NIL’s score will be based only on the content that exists at the https://landing.example.com

During the dry run, we'll provide two sets of scores with and without the application of this policy. Only the set of course without the application of this policy will be used in calculating the final score.

It is important that users understand which app they are using and redirecting between multiple origins hurts that goal.

Not a big fan of this proposal. Not sure how having redirects to the app url hurts the notion above. Like I mentioned specific to my apps I use the landing page url to give users like PH and TryMyUI a better understanding of what the app does + education. This is built using Server Side Rendering due to potential SEO gains.

However, the app itself is built using a Single Page Application which is not good for SEO but great for app development and speed.

If anything I propose that app developers are allowed 2 input fields when submitting an app for app mining.

One url for testing nil (app specific url) One url for TryMyUI (landing page)

There are instances where this could be the same url.

cc: @larrysalibra @jeffdomke

@kkomaz you still can redirect from example.com to example.com/app

Sounds like NIL has the dry run data for this anyhow, we can share that and get more feedback before deciding on next steps.

As we are growing, I have some thoughts to share: Along with progress as any other young project, it involves rebranding or renaming some parts, products, or changing domain names. And as the security model is origin-based, we can not ask all the users to rejoin; it cost a lot of trouble, moving data, etc. So the way I can think of is to land the users to NewOrigin.com, on sign in, redirect her to OldOrigin.com, and after the process is done, go back to the NewOrigin.com. I think we can not limit the apps to stick to the old address for a lifetime unless we have a feature to change the origin of the apps on a rename or likewise actions. We can have control over this move, but limiting it will limit the growth of apps.

@larrysalibra Could you share the dry run data?

@Walterion1 There is an open issue for data migration (including to new domains) for the Blockstack browser: https://github.com/blockstack/blockstack-browser/issues/1787

I think we can not limit the apps to stick to the old address for a lifetime unless we have a feature to change the origin of the apps on a rename or likewise actions.

I would try to push fixing the browser than including a temporary rule to app mining.

We’ve seen a number of apps that submit one app origin to app mining and redirect users to one or more origins when the user tries to use the app. Blockstack app security is centered around an app origin - when a user authorizes access to Gaia storage for an app, they’ve giving access to a particular origin. Redirecting users to different app origins without their permission is dangerous and confuses them as to which app they’re actually using.

We attempted to manually determine how many apps in app mining exhibit this behavior in the past couple months. In October 2019’s app mining session, we conducted a dry run and counted at least 27 apps that redirected users to other app origins besides the one that was submitted to app mining.

We also found that even when a user is proactively looking out for an origin change in the address bar, it was very easy to miss. Put another way, even well-educated users have trouble keeping track of where they are on the web.

We propose that going forward, our review of apps will conclude when the app navigates away from the submitted app origin (excluding any navigation to the Blockstack Browser/authenticator). we recommend this as a policy change instead of a scoring item.

There are two reasons for this. 1) it moves us closer to clearly defining what an app is - an app is some code distributed from a name. Right now that name is the app origin, in the future it will be a Blockstack name. Different name, different app. 2) Trying to treat this as a scoring item make is complicated: Testing manually is very challenging because the tester needs to pay very close attention to what’s in the address bar. Testing it automatically is also challenging because an extension performing the test needs to maintain state across arbitrary app origins and somehow determine that arbitrary collection of apps origins is part of one app.

This policy will take effect in the app review period that begins on December 1, 2019 (November 2019 cohort).

See the following forum issue for other proposed scoring and policy changes: https://forum.blockstack.org/t/november-2019-nil-scoring-proposals/9494?u=larry

Regardless of how I feel about this, before imposing this new rule you need to make sure app developers are given ample time to be allowed to change the origin. It seems like 12/1 is a bit aggressive. No email or notification is sent out prior to this change. Usually @GinaAbrams sends out an email with the change log and should provide a link for app developer to change the desired url.

I'm sorry, I just don't get this. I use apps constantly that have a different origin for their "app". I've never thought that it's a problem if someone uses a subdomain like app.x.com.

But that's my personal opinion on the issue. I definitely think we should not push this change through without giving developers more warning. I just don't think lots of apps will even know that their app will be disqualified.

You should sign-in from the auth domain, not from anywhere else and then arrive at the auth domain.

I think landing pages are still valid and should be used. @larrysalibra Can you clarify this?

In Blockstack, an app is a name. A different name is a different app. Unlike ICANN DNS, Blockstack Name System doesn't have an ownership or control relationship between "subdomains" and parent "domains". Example: larry.id.blockstack is a "subdomain" of both "id" and "blockstack" but it is not controlled or owned by the owner of the id.blockstack name or the creator of the blockstack namespace. This is different than landing.app.example.com. The controller of app.example.com has the power to unilaterally decide what content.

You should sign-in from the auth domain, not from anywhere else and then arrive at the auth domain.

Yes - and you shouldn't navigate away from that name in the process of using the app. If your app navigates away from the name you submit to app mining, it is a different app.

I think landing pages are still valid and should be used. @larrysalibra Can you clarify this?

I don't have a problem with landing pages. If your app is https://app.example.com and you have a bunch of landing pages at https://landing.example.com and https://example.com - this is fine. Submit https://app.example.com to app mining, don't submit https://landing.example.com or https://example.com.

I don't get this @larrysalibra . The issue is mainly about SSR vs. SPA and the choice wrt how it affects app's seo, positioning, marketing and complexity of app logic. The choice should be with the developers. When we have plenty of centralized apps that provide much better performance technically, it means we need to work hard to give our users extra context and awareness about the app and SSR helps us in doing so. Having said that many of us choose SPA for the obvious reasons of speed and complexity for the app itself. I don't think forcing developers to choose one over other is a better way forward. If at all you think this is fundamentally against Blockstack ethos, which I strongly differ, the more sensible thing to do is to allow developers submit two different urls and NIL reviews app page. Why should that be a problem?

If app publishers can submit both a landing page url and the auth domain than there shouldn't be a problem for web apps.

Any comments on mobile apps?

Neha03G [email protected] schrieb am Do., 28. Nov. 2019, 06:39:

I don't get this @larry https://github.com/larry. The issue is mainly about SSR vs. SPA and the choice wrt how it effects app's seo, positioning, marketing and complexity of app logic. The choice should be with the developers. When we have plenty of centralized apps that provide much better performance technically, it means we need to work hard to give our users extra context and awareness about the app and SSR helps us in doing so. Having said that many of us choose SPA for the obvious reasons of speed and complexity for the app itself. I don't think forcing developers to choose one over other is a better way forward. If at all you think this is fundamentally against Blockstack ethos, which I strongly differ, the more sensible thing to do is to allow developers submit two different urls and NIL reviews app page. Why should that be a problem?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/blockstack/app-mining/issues/147?email_source=notifications&email_token=AALBYWPBAAWSVXKACVSXAZDQV5KQTA5CNFSM4ITGGGB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFLQANA#issuecomment-559349812, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALBYWKDANTSOSTPZ3R45QDQV5KQTANCNFSM4ITGGGBQ .

Any comments on mobile apps?

The origin submitted to app mining that has the link to the ios or android app store should also be the origin that the app uses for sign in.

@friedger do you have any other thoughts about mobile?

@larrysalibra Lately i've submitted dclouds in October to app mining program as https://app.dclouds.online, and the landing page was https://dclouds.online, but the authenticaiton process and the redirection was fine i guess, cuz i was logging in from https://app.dclouds.online, and the redirection takes me back to https://app.dclouds.online, but i had a bad review in trymyui, cuz people couldn't reach to understand what is the app doing, cuz everything is explained in landing page. So what's your thoughts should a developer do, to go with the right flow, and give the user better quality apps? Should we make the login page has more details and landing page for SEO and marketing things?

I don't have a problem with landing pages. If your app is https://app.example.com and you have a bunch of landing pages at https://landing.example.com and https://example.com - this is fine. Submit https://app.example.com to app mining, don't submit https://landing.example.com or https://example.com.

The origin submitted to app mining that has the link to the ios or android app store should also be the origin that the app uses for sign in.

@larrysalibra Agree on that!

Should we make the login page has more details and landing page for SEO and marketing things? @uonuon Sounds like a good approach. If in the future app publishers can provide more urls then this approach could be reviewed.