Capability Model

[RichardMaher]

How would a lazy developer, in the absence of a mainline request(), employ the capability model from a Service Worker without an active UI?

Notification Background Fetch Background Synch Background GeoLocation

Is it not fair to say that the capability model is more like a "guideline" than a "rule" and the truth will out?

[marcoscaceres]

I don't know what you are asking. Can you please rephrase?

[RichardMaher]

I mean it is not necessarily the the responsibility of a given specification to police developer creativity to such an extent that a single, lowest-common-denominator, homogeneous, UX will prevail regardless of the individual Web App, business requirement, or user demographic.

Note that the capability model (where applicable) is a given as the "best" user experience today, but this was not always the case and conceivably may not be so in the future. It is also highly likely that a certain cultural demographic may actually prefer up-front or install time permission dialog.

My point is that its is over-reach and out of the terms of reference of spec developers to insist that you can have any colour Model-T as long as it is Black. Let user-demand/market-forces dictate what is a preferable or successful UX. No offence to the Mozilla people intended but I hope they'll agree that their current presence on the mobile platform suggest they have not always been right in knowing what people want.

Anyway, the real answer to your question is, I don't understand how a ServiceWorker can use the capability model to prompt for user permission with context when there is no active UI. Does that make more sense?

[marcoscaceres]

That makes sense, and I understand your position. Unfortunately, that position is at odds with browsers makers' security ux teams. Although we understand that certain apps will have different permissions requirements, we have to worry about literally billions, with a "b", of users being affected by these decisions.

the real answer to your question is, I don't understand how a ServiceWorker can use the capability model to prompt for user permission with context when there is no active UI.

It can't. That's by design. You need to show a page first, get permission to use a feature, then the SW can use the feature. Having said that, iOS's model of requesting permission, then letting you know that an app is accessing your location in the background (even if the app is "closed") works*... but still requires an upfront permission grant.

• I say it works in as far that I trust Apple to do due diligence via user testing of that permission prompt in iOS.

[RichardMaher]

Unfortunately, that position is at odds with browsers makers' security ux teams.

What position? Please quote what you are referring to. At least I ask for permission; the developers and spec writers of Background Sync deemed user permission as surplus to requirements. "They can always opt-out via an obscure setting". As much as the cynic in me would like to use the same strategy to get Background GeoLocation I believe the reputation of UWAs is far too important to squander on such short cuts.

we have to worry about literally billions, with a "b", of users being affected by these decisions.

I worry about the Billions with a capital "B" that are forced to use Native Apps, 99% of which ask for all privs at either download time or up front at first run. I weep for the billions who want to use Ultimate Web Apps for Tinder, GrindR, Dominos, Deliveroo, and to track their bike rides but are forced to use Native Apps because of the indifference of browser manufacturers :-(

That's by design. You need to show a page first, get permission to use a feature, then the SW can use the feature.

So you're happy with the Bundled Permission model in general or exclusively for Service Workers? But didn't you recently lobby for the removal of Permissions.request()? You're all for the Capability Model except when incapable? I'm not following any more, sorry.

[RichardMaher]

Also curious how Usurper Web Apps becoming first-class Apps, will effect people's opinions regarding the bundled permission model. If a user can always go to the App Drawer and selectively disable/enable permissions for a given UWA, what is the problem with asking for them all upfront?

More to the point, without a Manifest declaration of expected/superset-of permissions how can that Settings-App-Permissions dialog make any contextual sense? Enable microphone-permission when the application never uses it? Have App-specific warning messages like Chrome when a user tries to turn off Location access?

BTW, I believe Chrome next or next+1 will have first class Apps installed on Android.

Admittedly if a privilege is turned off my Apps throw up a fullscreen error at run-time until the permission is turned back on, but you have to agree that first-class Apps is a game changer?

[RichardMaher]

Another alternative?

The Poor User Experience model -

"so requiring user permission would be a poor experience" I'm all for it! Is there a litmus test or formalized criteria that covers "poor"?

AKA: - The Surprise Model?

[marcoscaceres]

Closing as answered.