NIL scoring for mobile apps

[apoonam]

@GinaAbrams Thanks for suggesting to start this issue.

What is the problem you are seeing? Please describe. As confirmed by @larrysalibra, NIL currently is unable to score mobile and native apps on use of the sandbox, cookies and third party requests. Because of the current limitation, mobile apps are given a blank which are effectively counted as 0s for these parameters, severely affecting the total NIL score for the mobile apps.

How is this problem misaligned with goals of app mining? The current scoring method though unintentionally but unfairly penalizes mobile apps in the app mining program. This creates a non level playing field for mobile apps compared to web apps. Web apps already outnumber mobile apps in app mining program by a huge margin and this will further disincentivize mobile app developers to participate in the program.

What is the explicit recommendation you’re looking to propose? Either of the following two options could be chosen,

1. Take only the avg of the scores of parameters being reviewed. Or,
2. Postpone implementation of new NIL rules till NIL comes up with a review mechanism for mobile apps.

What is the dry run period (if any) The dry run has already been concluded for December and the effect can be seen. Any one of the recommendations can be implemented right away.

Describe your long term considerations in proposing this change. At this stage where mobile apps are already too less in blockstack ecosystem, the current scoring mechanism will further discourage developers to venture into mobile app development significantly affecting number of mobile apps in the ecosystem. Mobile functionality is essential for adoption by a wider user base and will be critical for achieving milestone 2 (2020 Q1-Q2) of reaching first million users on the blockstack network. Creating a level playing field for mobile apps in the app mining program will encourage new mobile developers, bring more awareness to mobile users thereby bringing new set of blockstack users to the community.

[njordhov]

Mobile functionality is essential for adoption by a wider user base and will be critical for achieving milestone 2 (2020 Q1-Q2) of reaching first million users on the blockstack network.

The web has a wide user base including those using browsers on mobile, so native mobile is actually neither critical nor essential for reaching a million users and beyond.

[hammadtq]

Mobile functionality is essential for adoption by a wider user base and will be critical for achieving milestone 2 (2020 Q1-Q2) of reaching first million users on the blockstack network.

The web has a wide user base including those using browsers on mobile, so native mobile is actually neither critical nor essential for reaching a million users and beyond.

71% of America's internet traffic is coming from mobile devices that is further divided into equal share between mobile web-browsers and mobile apps. [Read more here] This article is focused on e-commerce and retail, users of long-term brands such as Facebook and Twitter should have much higher percentage of users coming from the mobile apps. This is just the US, mobile-penetration is higher in 3rd world countries.

The web is predominantly on mobile now, apps serve users better. This is only blockchain and crypto community that is trying to re-invent the web by sticking to the browsers.

Also, it fails to amaze me now how Blockstack implements policies without any regard to which subset of apps these policies are going to affect or how future-proof they are even if it's necessary to implement solutions like Can't be evil sandbox to evolve and roll-over to the next phase of check and balance. I totally agree we needed things like open source and detecting if sites redirect users to somewhere else but things like detecting "cookies" and them holding a number on the points table - how do you plan to implement that for mobile apps or does Blockstack consider mobile-apps a very small subset of apps for the foreseeable future?

Arguably it's not that hard for mobile-apps as well if they are open source and even with closed source you can easily detect which URLs they are pinging at the backend. Open sourcing them could allow see to see which 3rd party packages they are using such as Facebook analytics.

By continuing to allow Digital Rights Reviewer to not support mobile apps, Blockstack is essentially discouraging mobile apps from joining the program.

[friedger]

This is only blockchain and crypto community that is trying to re-invent the web by sticking to the browsers.

I strongly disagree! Two companies benefit most from app distribution. There is less and less distinction between native apps and PWAs. Microsoft Store is embracing PWAs from the beginning. Google Play has published some tools for PWAs. And even Apple is moving forward.

[hammadtq]

This is only blockchain and crypto community that is trying to re-invent the web by sticking to the browsers.

I strongly disagree! Two companies benefit most from app distribution. There is less and less distinction between native apps and PWAs. Microsoft Store is embracing PWAs from the beginning. Google Play has published some tools for PWAs. And even Apple is moving forward.

This article is just suggesting to use PWAs to circumvent iOS app-store reviews. Lets assume I buy the argument that PWAs are better for decentralized internet (Apple is no way against it by the way but is susceptible to remove the app on certain government pressures and of course you are subject to some government reporting if you are using encryption in your app) - lets say we all should just build PWAs and somehow find our way to a user's home-screen. Now, shouldn't Blockstack should just stop supporting Android and iOS native SDKs and publicly state that you should just build a web-app and not native app if you want to be a part of app-mining? Instead of making them go on disadvantage silently without giving clear guidelines of what is favoured here?

Also just to add: App stores are app discovery portals, that's their biggest advantage. Otherwise a PWA will need to go through the whole SEO/SMM thing for discovery. To be fair, thats what already web apps need to go through but if you have an easy door to discovery why would you not take advantage of that?

[sdsantos]

I agree that either: a) There's an official communication saying native apps are not recommended on Blockstack. b) Native apps need to have an equal footing in the app mining program.

I would prefer b). Although mobile apps on app stores depend too much on good will from monopoly companies, it's still a huge market and an important growth source. Example: 4 of the top 10 apps on theblockstats.com have native apps.

And it's not like we can't monitor network traffic on native apps. We might not be able to enforce a sandbox mode like on the web, but we can check if they're not being evil. Although NIL decided to start with checking web apps, I believe native apps should not get a 0 score until a tool is develop to check them as well.

[apoonam]

I guess nobody in Blockstack PBC is denying the importance of mobile apps for the ecosystem or bringing in new users into the network. It's just that there isn't any communication on how mobile apps are going to be reviewed by NIL on the new NIL policies. Will request @GinaAbrams , @hstove or @larrysalibra to update on how scores are going to be administered this month so that we can have clarity on this issue.

[njordhov]

@hammadtq The Mobile web vs Mobile apps article is outdated and biased; It is from 2017 and posted by a company that promotes their mobile app builder and services.

[GinaAbrams]

cc @larrysalibra to please add additional comments 🙏

[larrysalibra]

I actually agree with most of the comments here.

Native mobile apps are great and provide the optimal user experience for a wide range of applications.

Web is wide reaching and works very well on mobile as well.

We can put software between web apps and the rest of the world to get the massive data/privacy leakage that happens on the web under control.

The same problems exist in native mobile apps - to many extents it's even worse, but only the operating system manufactures are really in a position to do anything about it.

If we're scoring solely on how Can't Be Evil an app is - we can tell what a web app is doing. We can expose that behavior to the user and provide some sorts of guarantees about what the app will or will not do.

We can't tell what a native mobile app is doing and can't give the user any guarantees about its behavior.

Is that fair? Of course it's not. But we don't operate in a fair world - we operate in a competitive adversarial world where operating system vendors and hardware manufacturers (the same company in the case of Apple) wield enormous power to determine what we can and cannot do.

In the context of Can't Be Evil - it absolutely puts native mobile apps at a disadvantage. And that's really unfortunate, because native mobile apps deliver some of the best user experiences and this handicaps them.

Having said that, I think that it's not fair that I didn't give a clear answer to how we are going to deal with the scoring of mobile apps.

This problem regarding constraints that native mobile apps bring is only going to get worse in the future as we introduce apps distributed by blockstack names ("Stacks Publishing") and other uses of our technology stack.

I propose that this month, native mobile apps are exempt from the Can't Be Evil-related items and rated only on Gaia and Auth. In the future, in the absence of significant changes to app mining, I'd propose that apps that can't be rated on a particular metric because of the choice of form factor or technology get a zero in that category.

[sdsantos]

@larrysalibra

Some questions: a) What about those who have both Web and Mobile apps for the same product? b) And although there's no way to enforce "Can't be evil" on native apps, what about scenarios where we can check that they are not being evil? For example, an open source Android app with an APK self-published? Or monitoring a native app traffic during usage?

[larrysalibra]

a) We always check web if an app has both web and mobile b) We need to have a way to not only monitor but also prevent the behavior. I'm not sure how you can do that on mobile platforms without rooting devices. Would love suggestions though.

[sdsantos]

I don't have a suggestion for enforcing it for mobile/native apps.

But if a native app:

• is open-source
• has a predictable compilation/packaging/building process
• is self-published and includes a verification hash

Couldn't that ensure that they aren't evil, even without enforcement?

[friedger]

At f-droid.org, they have a monitoring and enforcement of certain behaviors for Android apps established. It might be possible to do extend these for can't be evil behavior

Sérgio Santos notifications@github.com schrieb am Mo., 13. Jan. 2020, 17:06:

I don't have a suggestion for enforcing it for mobile/native apps.

But if a native app:

• is open-source
• has a predictable compilation/packaging/building process
• is self-published and includes a verification hash

Couldn't that ensure that they aren't evil, even without enforcement?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/blockstack/app-mining/issues/216?email_source=notifications&email_token=AALBYWNYXDRCSOJDZZWMS3LQ5SGRDA5CNFSM4KCVRTNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIZI6GA#issuecomment-573738776, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALBYWOQX24WTQFRXSPGCRLQ5SGRDANCNFSM4KCVRTNA .

[sdsantos]

I just realised that the extension allows for any request to the same domain. And, of course, we're not monitoring the server-side code, let alone enforcing anything. That sounds way worse than mobile apps, where at least we can monitor what they're doing.

Isn't saying on the extension that it's preventing evil misleading for web apps with a custom server?

Just want to clarify that I'm all for "Can't be evil" apps, that at least I can verify to be trustworthy. Enforcement is nice to have, but writing-off mobile apps that have nothing to hide seems harsh.

[larrysalibra]

I just realised that the extension allows for any request to the same domain. And, of course, we're not monitoring the server-side code, let alone enforcing anything.

Just v1. Future versions will address that.

Isn't saying on the extension that it's preventing evil misleading for web apps with a custom server?

Happy to accept pull requests with better copy!

[hammadtq]

I propose that this month, native mobile apps are exempt from the Can't Be Evil-related items and rated only on Gaia and Auth. In the future, in the absence of significant changes to app mining, I'd propose that apps that can't be rated on a particular metric because of the choice of form factor or technology get a zero in that category.

@GinaAbrams can we please accept Larry's proposal here? I just reviewed the draft scores of this month, every other score improved this month for my app but due to Can't be evil new scores the app actually dropped from 53rd to 97th. I assume this is the case with other native apps as well. This is not fair for native apps developers. I propose since we are going for radical changes in app-mining, this score should not be applied to native apps for January and February runs.

[apoonam]

Having said that, I think that it's not fair that I didn't give a clear answer to how we are going to deal with the scoring of mobile apps.

I propose that this month, native mobile apps are exempt from the Can't Be Evil-related items and rated only on Gaia and Auth. In the future, in the absence of significant changes to app mining, I'd propose that apps that can't be rated on a particular metric because of the choice of form factor or technology get a zero in that category.

@hammadtq Larry has already proposed this. I have been on this issue since a month and I believe after @larrysalibra's comment there shouldn't be any doubt regarding jan-feb scoring. cc @GinaAbrams

[larrysalibra]

@hammadtq @apoonam I reiterated the proposal to exclude these metrics for mobile & native apps when sending the PBC team the results.

[GinaAbrams]

Thanks all, this has been updated in the audit results.

[hammadtq]

Thanks all, this has been updated in the audit results.

Thanks @GinaAbrams for removing negative Z scores for Redirect, 3rd party and Opt-in metric but there is still another issue since other apps are awarded a mark in these boxes the total NIL score for a fully compliant web app is coming across as 0.6663102542 while because native apps are not getting any score, they are reduced to 0.2686711054.

This is affecting native app rankings. Since, the audit spreadsheet is constructed in this way now, I will suggest giving native apps 1 mark each for new NIL measures as well to remove the unfair disadvantage.

[hstove]

Since, the audit spreadsheet is constructed in this way now, I will suggest giving native apps 1 mark each for new NIL measures as well to remove the unfair disadvantage.

This would introduce a new problem, where apps are given an unfair advantage around digital rights by immediately scoring higher than web apps, and NIL has explicitly stated that web apps are better for digital rights.

If you want to make a new proposal for this change, you are definitely free to do so.

[apoonam]

@hstove this puts us absolutely in a disadvantageous position for the mobile and native apps. I have been behind this issue for a month incessantly mailing the app mining team. Nothing was communicated to us in advance, it was when I followed up 3-4 times this issue was even considered. You want to make a decision that blockstack supports web apps and considers mobile apps not appropriate for digital rights at least give us a heads up. This is just about that. The audit results have already been announced and now you suggesting to start a new ticket for this making it a separate issue. This is like resorting to red tapism to deviate from the main issue. cc @hammadtq . As far as giving advantage to mobile/native apps is concerned NIL has already announced that it will propose zero for the mobile apps for the next months. This month was already exempted and we are unnecessarily bureaucratising the issue.

[apoonam]

@larrysalibra already mentioned to me in the mail that PBC should have communicated about the mobile thing before hand to us. Even then I followed up consistently and we reached the conclusion just yesterday and now you are asking us to start a new ticket two days after results are announced?

[hammadtq]

NIL has explicitly stated that web apps are better for digital rights.

This is a very interesting statement coming from PBC. That definitely means PBC officially discourages all natively packaged mobile apps. So, no mobile apps at all? I will strongly encourage PBC to tell us if that is the case then how it is communicated to the developers? Should we add a new ticket to ask you to write this on your website, newsletter and encourage you to remove all Swift and Android SDKs from Github?

I will again like to remind everyone here that no development is free. It takes cost, time and effort to write and promote an app - even one that is not on the scale of Facebook or Twitter yet. Developers are a stake-holder in a program like app mining. We understand this is a bold experiment and no one is yet sure how this would work but PBC being a centralized authority can not go around changing rules in the middle of the program and then not listening and penalizing a subset of the apps because a reviewer has no solution (yet) to track a new subset of rules?

This would introduce a new problem, where apps are given an unfair advantage around digital rights by immediately scoring higher than web apps

I would like to remind you that until previous results NIL scores were same for everyone and no one was at disadvantage and that is all what we want as native app devs. If you have a solution to track and implement new NIL rules on native apps you should communicate them to us well in advance otherwise all apps should be given equal score.

[Walterion02]

Please let me agree with @hammadtq and @apoonam, as I feel the same when we are working on Native apps. Check #156 for more info.