[whatwg] Popular Background Geolocation question on StackOverflow

[Richard Maher]

FYI This question on StackOverflow has now had over 1000 views: -
https://stackoverflow.com/questions/44233409/background-geolocation-serviceworker-onmessage-event-order-when-web-app-regain

Please explain why nothing is happening.

Re: [whatwg] ServiceWorker bottle-neck design flaw - MS Edge to the rescue?

[Richard Maher]

EDIT 1

Ok, it might have been Safari/Webkit but reading this
<https://webkit.org/blog/8090/workers-at-your-service/> it looks like 1
process for all ServiceWorker threads plus another to monitor/start/stop,
but only one simultaneous SW instance per domain (plus that dodgy iFrame
logic webkit has got going on)

So if neither Webkit or Edge do what my memory tells me then is it not a
good performance idea? (Barring reduced hit rate on SW recycling)

EDIT 2

On third thoughts, the fact that everything in a ServiceWorker is
Asynchronous or verbotten means Fetch, Push, Travel, events can all
multiplex to the same SW instance without much performance degradation.

Oh Well, I'm back to "Stuffed if I know why no one is implementing the
TravelManager :-("

FWIW The WebKit implementation of shared memory buffer must surely
necessitate a Synchronous API? Breaking one of the major premises of SW
design?

EPILOG

I apologise for spamming the recipients here even though I did it
knowingly. I won't do it anymore. I didn't believe I was reaching an
audience so I just kept pulling leavers and pushing any and all buttons
available.

I have been made aware that, unbeknownst to me, some of the right people
were hearing what I had to say and the TravelManager idea was gaining
traction. To those people let me just say that I spent a fair bit of time
on the Brotkrumen Web App which demarcates UA Developer and Web Developer
contributions succinctly, provides smooth Google Map marker movement via
CSS transitions to get the mug punters looking and, most importantly, is a
fully working, fully documented, complete, sscce which provides real-time
feedback on the ratio of ServiceWorker instances to Geolocation updates!

If there is a open/tolerant forum where people discuss such things then
please let me know. Once again, *no one* can tell me there's anything wrong
with the idea. OTOH I can tell you heaps of things that are wrong with the
"alternative" WakeLock or Sensor ideas.

I also have a few good ideas for permissions/visibility on Background
Geolocation if anyone is interested.

BTW when I said repeatedly that I am happy to "go away" it was on the
proviso that the two issues I've been banging on about for two years were
implemented.

1) Broadcast notifications where the client/UA can subscribe to a Topic.
Once again W3C let us down but thanks to FCM we can access this much needed
functionality so I let it go.

2) Background Geolocation. As ShamWow guys says "It sells itself". Why,
WHY, *WHY* are people saying NO to this?


Cheers Richard


On Fri, Mar 2, 2018 at 11:22 AM, Richard Maher <mahe...@googlemail.com>
wrote:

> As you may be aware, I have been lobbying strongly here
> <https://stackoverflow.com/questions/44233409/background-geolocation-serviceworker-onmessage-event-order-when-web-app-regain>,
> and here
> <https://stackoverflow.com/questions/45206149/expected-ratio-of-serviceworker-instances-to-geolocation-updates>,
> and especially over there
> <https://github.com/w3c/ServiceWorker/issues/745> for the introduction of
> a background geolocation capability with Web Apps.
>
> So frustrated had I become that I spent the time to develop and document a
> POC example with everything UA developers and Web App developers need to do
> to implement background geolocation - documented sscce here
> <https://drive.google.com/open?id=0B7Rmd3Rn8_hDNW1zSWRoXzBTclU> and, to
> date, no one can tell me there’s anything wrong with it.
>
> In this technical feed-back vacuum my mind began to ponder why, and then
> drifted to “Cui Bono?”, and ultimately to conspiracy theories. For example:
> - Phonegap/Cordova developers bribing W3C to sandbag BackgroundGeolocation
> efforts.
>
> But only today did it dawn on me like a bolt of lightning to the brain!
> There is a fundamental design flaw with the current ServiceWorker
> design/implementations in that there is only ONE per UA. Jake Archibald et
> al have been so blinkered with offline-first, cache, and the browser being
> a proxy-server that they will not tolerate anything else monopolizing the
> SW thread to the detriment of their fetch performance stats.
>
> But God Bless Edge, notwithstanding their tardy arrival on the scene, who
> I believe have specialist SW instances for PUSH, FETCH, A.N.Other. This is
>  *fantastic*!!!
>
> Just add another specialist instance “GeoLocation” and we’re away.
>
> Please don’t let self-interest stand in the way of this essential
> functionality. Let’s go!
>
> But my question here is this: - Can someone please confirm that Edge
> implements multiple, specialist SW instances?
>
> Cheers Richard Maher
>
>

[whatwg] ServiceWorker bottle-neck design flaw - MS Edge to the rescue?

[Richard Maher]

As you may be aware, I have been lobbying strongly here
<https://stackoverflow.com/questions/44233409/background-geolocation-serviceworker-onmessage-event-order-when-web-app-regain>,
and here
<https://stackoverflow.com/questions/45206149/expected-ratio-of-serviceworker-instances-to-geolocation-updates>,
and especially over there <https://github.com/w3c/ServiceWorker/issues/745> for
the introduction of a background geolocation capability with Web Apps.

So frustrated had I become that I spent the time to develop and document a
POC example with everything UA developers and Web App developers need to do
to implement background geolocation - documented sscce here
<https://drive.google.com/open?id=0B7Rmd3Rn8_hDNW1zSWRoXzBTclU> and, to
date, no one can tell me there’s anything wrong with it.

In this technical feed-back vacuum my mind began to ponder why, and then
drifted to “Cui Bono?”, and ultimately to conspiracy theories. For example:
- Phonegap/Cordova developers bribing W3C to sandbag BackgroundGeolocation
efforts.

But only today did it dawn on me like a bolt of lightning to the brain!
There is a fundamental design flaw with the current ServiceWorker
design/implementations in that there is only ONE per UA. Jake Archibald et
al have been so blinkered with offline-first, cache, and the browser being
a proxy-server that they will not tolerate anything else monopolizing the
SW thread to the detriment of their fetch performance stats.

But God Bless Edge, notwithstanding their tardy arrival on the scene, who I
believe have specialist SW instances for PUSH, FETCH, A.N.Other. This is
*fantastic*!!!

Just add another specialist instance “GeoLocation” and we’re away.

Please don’t let self-interest stand in the way of this essential
functionality. Let’s go!

But my question here is this: - Can someone please confirm that Edge
implements multiple, specialist SW instances?

Cheers Richard Maher

[whatwg] It's BackgroundGeolocation Zeit!

[Richard Maher]

Richard Maher <mahe...@googlemail.com>
10:00 AM (2 minutes ago)
to Chaals, Ben, WHAT, Chaals, Natan, public-geoloca., ehsan, alia, jmann,
beidson, eoconnor, weinig, Kenji, jungkee.song
Mate, how does Background Geolocation get to bypass this narcissistic
obstructionism? Are there no adults at W3C? Oh, Mozilla pays a lot so we
have to have him?

Two years precious time squandered due to him and Jerk bloody Archibald. Is
there no accountability in your autonomous collectives?

Merit-based resource allocation?

Re: https://discourse.wicg.io/t/proposal-expose-geolocation-
to-service-workers/2588

<https://discourse.wicg.io/u/marcosc>
marcosc <https://discourse.wicg.io/u/marcosc>
22h
<https://discourse.wicg.io/t/proposal-expose-geolocation-to-service-workers/2588/38>

FYI, I’ve banned @Richard_Maher
<https://discourse.wicg.io/u/richard_maher> from
our discourse for repeated code of conduct violations.

If he returns under a different alias (which he tends to do), please let me
know.

Please refrain from engaging with him on Discourse or standards discussions.
1 Like
<https://discourse.wicg.io/t/proposal-expose-geolocation-to-service-workers/2588/38>
<https://discourse.wicg.io/u/marcosc>
marcosc <https://discourse.wicg.io/u/marcosc>
21h
<https://discourse.wicg.io/t/proposal-expose-geolocation-to-service-workers/2588/39>

I’ve also deleted @Richard_Maher <https://discourse.wicg.io/u/richard_maher>
 posts, as they are just noise.

Apologies to participants in this thread for not taking action sooner. This
individual has been trolling our community for a long time, and, despite
numerous pledges from him to behave - or claims that he will go away, he
keeps coming back.

"Noise"? Was there someone else that contributed anything useful? Fine, ban
me (again) but burn my books? Really?

How do you blokes live with yourselves :-(

BTW. I believe you should update your CoC more in line with the other
communist regime's banning of "disagree": -

“Disagree”.

This is what it prompts:

“Sorry, this content violates the laws and regulations of Weibo’s terms of
service.”
Just replace Weibo with W3C/IETF :-(

https://www.perthnow.com.au/technology/internet/chinas-
war-on-words-anything-be-it-a-phrase-or-picture-that-can-be-
used-to-insult-xi-has-been-banned-ng-a8e5a9d558b3ed0465e1fc020e2d6c2c


PS. I've heard that North Korea and the Church of Scientology are also
doing great things in the free-speech space.


On Tue, Feb 27, 2018 at 8:23 AM, Richard Maher <mahe...@googlemail.com>
wrote:

> I guess that's why, when I lived in Munich, the English cinema was packed
> with locals (who seemed to laugh at odd moments :-)
>
> Anyway what has to happen to get Background Geolocation up?
>
> On Tue, Feb 27, 2018 at 6:47 AM, Chaals Nevile <cha...@yandex.ru> wrote:
>
>> You have no need to reproach yourself Chaals. If you dekete your post
>>> then I will have dekete mine then we’ll end up in a cycle of revisionism
>>> and book burning.
>>>
>>
>> It's a noble profesion with an honourable history
>>
>> C’mon, we were a little bit funny?
>>>
>>
>> Well yeah, but to be honest only a little bit. And only in English. I
>> watched Princess Bride once in Spanish and realised why my spanish friends
>> didn't think it was funny. The translation is shit - totally lacking in
>> grace, humour or style, as is far too often the case for translations into
>> spanish.
>>
>> cheers
>>
>

Re: [whatwg] Expose GeoLocation to workers #745

[Richard Maher]

Yeah that's what I thought :-(

On Tue, Feb 13, 2018 at 8:12 AM, Richard Maher <mahe...@googlemail.com>
wrote:

> Regarding the very recent comments following on from: -
> https://github.com/w3c/ServiceWorker/issues/745#issuecomment-344128148
>
> Can any of you please explain what is wrong with the complete POC solution
> here: -
> https://drive.google.com/drive/folders/0B7Rmd3Rn8_hDNW1zSWRoXzBTclU
>
> If the proposed solution is somehow deficient or not fit for purpose
> please let me know!
>
> I believe the permissions/user-visibility conundrums to be the only loose
> end.
>
> Please also note the plethora of use cases detailed by numerous people
> over the years that can be found here: -
> https://github.com/w3c/ServiceWorker/issues/745
>
> I do not understand Marcos' claim that there is little browser interest
> when Edge and Chrome are waiting on a specification to implement. Firefox
> already allows tracking of users in the background today.
>
> Cheers Richard Maher
>

[whatwg] Expose GeoLocation to workers #745

[Richard Maher]

Regarding the very recent comments following on from: -
https://github.com/w3c/ServiceWorker/issues/745#issuecomment-344128148

Can any of you please explain what is wrong with the complete POC solution
here: -
https://drive.google.com/drive/folders/0B7Rmd3Rn8_hDNW1zSWRoXzBTclU

If the proposed solution is somehow deficient or not fit for purpose please
let me know!

I believe the permissions/user-visibility conundrums to be the only loose
end.

Please also note the plethora of use cases detailed by numerous people over
the years that can be found here: -
https://github.com/w3c/ServiceWorker/issues/745

I do not understand Marcos' claim that there is little browser interest
when Edge and Chrome are waiting on a specification to implement. Firefox
already allows tracking of users in the background today.

Cheers Richard Maher

Re: [whatwg] How to handle Session Expiry in ServiceWorker

[Richard Maher]

It seems there has been discussion on this before. Please see GitHub




I think that background re-authenticating should be infrequent enough that
a notification of the sign-in or failure is an appropriate and
user-friendly solution.

Please comment over there if you have any ideas!

[whatwg] How to handle Session Expiry in ServiceWorker

[Richard Maher]

If a Fetch in my ServiceWorker receives a 401 from the server how do I
re-authenticate with the server if I have no focused or foregrounded client?

NB: I'm talking about POST requests updating the server and not just
reading from cache until the network is back.

Bring the client back into focus? Scary for user with no action causing
that reaction and they may not be there to login again anyway.

What does Background-Synch do if it gets a 401?

If navigator.credentials was surfaced in a ServiceWorker that would be
enough!

Sessions that never expire?

What are other people doing?

Yet again I'm banned from W3C/IETF Github :-(

If someone could add the following to ServiceWorker issues
 that would help: - Please
see Use-Case


If a User Session has expired a ServiceWorker currently has no mechanisms
available to re-authenticate with the server as there is no heuristic
mechanism available for determining credentials.

If the credentials.get() was available then re-authentication could take
place transparently. If federated (say Google) then if the user had logged
out then that state would be honoured.

[whatwg] When to use the new GeolocationSensor API?

[Richard Maher]

When would one opt to use the Sensor GeoLocation
 API as opposed to the
existing standard navigator.geolocation.watchPosition?

Can someone explain the added value of this second API or the use-cases
that can be solved by the sensor API that cannot be handled here
?

The Web App world desperately needs a background geolocation capability but
the sensor API architecturally prohibits this.

What is the point of the following redundant interface to geolocation: -

let sensor = new GeolocationSensor({ accuracy: "high" });

sensor.onreading = function(event) {
var coords = [sensor.latitude, sensor.longitude];
updateMap(null, coords, sensor.accuracy);};

sensor.onerror = function(error) {
updateMap(error);};
sensor.start();

If technical merit contributes to W3C/IETF resource allocation surely the
battery efficient background geolocation solution proposed here
 is what
should be promoted?

Re: [whatwg] Expected ratio of ServiceWorker instances to Geolocation Updates

[Richard Maher]

Please be advised that, as promised/threatened, I have added the Trip
Summary page and you can now map and replay your trip on Google Maps.

The new version of the code is at the same link
https://drive.google.com/open?id=0B7Rmd3Rn8_hDNW1zSWRoXzBTclU

Most important design/proposed-specification change is that TravelManager
subscription should now be Client specific. The TravelEvent must contain
the intended Client.id (TravelEvent.source.id). This means that the UA must
monitor and filter GeoLocation updates per client. I have also added new
demo functionality such as a Trip Summary that is displayed when you press
the "Arrive" button. The trip can also be replayed onto Google Maps by
pressing "Map Trip" or "Replay". If the last and next geolocation updates
for the trip are both visible in the Map window then smooth Marker movement
is achieved via CSS transitions.

*PLEASE* help Background GeoLocation get up and help Web Apps compete with
Native Apps!

If there is something wrong with my TravelManager solution design then let
me know. Tear holes in it!

On Thu, Jul 20, 2017 at 6:36 PM, Richard Maher <mahe...@googlemail.com>
wrote:

> For some time I've been arguing with W3C/IETF (and anyone else who'd
> engage) that ServiceWorkers are the ideal platform to host the Background
> Geolocation functionality that Ultimate Web Apps need in order to compete
> on a level playing field with Native Apps. The sticking point is usually
> the fleeting nature of a ServiceWorkers' lifespan. I have always argued
> that it would be madness to kill them immediately and most implementations
> seem to agree. (Firefox being the most aggressive at 30secs see Bug at
> https://bugzilla.mozilla.org/show_bug.cgi?id=1378587 this behaviour
> prevails even with heaps of CPU/Memory)
>
> Anyway, in order to prove that I am right, and the likes of Jake Archibald
> are very much mistaken, I wrote a little Web App, Source code can be found
> here: https://drive.google.com/open?id=0B7Rmd3Rn8_hDNW1zSWRoXzBTclU
> (There is a aaa_readme.txt) All code is documented full and contains
> meaningful/witty variable names.
>
> Now it still needs a bit of work to provide a trip summary page and map
> the trip on Google maps but I think you'll get the idea and most
> importantly see the real world, actual, demonstrable relationship between
> Service Worker Instances and Geolocation updates? (I wanted to get it out
> before the Europeans disappeared for August
>
> So have I done something stupid here? Am I imagining that I only get a new
> Service worker instance when I'm stuck at the lights for an extended period
> on the way home and position updates are nowhere to be seen? Are my coding
> skills lamentable and testing skills non-existent?
>
> If not, then I have no idea why Web Apps are not allowed to satisfy these
> legitimate and very desirable user requirements. Sure, we'll get
> user-empowerment, permissions, and discovery right but let's get on with
> it? The TravelManagerPolyfill.js file is nearly all UA developers have to
> do!
>
> Q: Have I understood the ServiceWorker architecture correctly and
> implemented a valid heuristic interrogation of ServiceWorker instantiation
> over time?
>

[whatwg] Expected ratio of ServiceWorker instances to Geolocation Updates

[Richard Maher]

For some time I've been arguing with W3C/IETF (and anyone else who'd
engage) that ServiceWorkers are the ideal platform to host the Background
Geolocation functionality that Ultimate Web Apps need in order to compete
on a level playing field with Native Apps. The sticking point is usually
the fleeting nature of a ServiceWorkers' lifespan. I have always argued
that it would be madness to kill them immediately and most implementations
seem to agree. (Firefox being the most aggressive at 30secs see Bug at
https://bugzilla.mozilla.org/show_bug.cgi?id=1378587 this behaviour
prevails even with heaps of CPU/Memory)

Anyway, in order to prove that I am right, and the likes of Jake Archibald
are very much mistaken, I wrote a little Web App, Source code can be found
here: https://drive.google.com/open?id=0B7Rmd3Rn8_hDNW1zSWRoXzBTclU (There
is a aaa_readme.txt) All code is documented full and contains
meaningful/witty variable names.

Now it still needs a bit of work to provide a trip summary page and map the
trip on Google maps but I think you'll get the idea and most importantly
see the real world, actual, demonstrable relationship between Service
Worker Instances and Geolocation updates? (I wanted to get it out before
the Europeans disappeared for August

So have I done something stupid here? Am I imagining that I only get a new
Service worker instance when I'm stuck at the lights for an extended period
on the way home and position updates are nowhere to be seen? Are my coding
skills lamentable and testing skills non-existent?

If not, then I have no idea why Web Apps are not allowed to satisfy these
legitimate and very desirable user requirements. Sure, we'll get
user-empowerment, permissions, and discovery right but let's get on with
it? The TravelManagerPolyfill.js file is nearly all UA developers have to
do!

Q: Have I understood the ServiceWorker architecture correctly and
implemented a valid heuristic interrogation of ServiceWorker instantiation
over time?

[whatwg] Permissions required for Background GeoLocation

[Richard Maher]

When it comes to an Ultimate Web App tracking a user's location in the
background (while UWA is backgrounded or phone is asleep) how can the user
(and Web Standards) ensure that the user is not tracked covertly,
maliciously, or unintentionally?

Can any please help, offer opinions, with the "best" way to: -
1) Ensure that a user has authorized the UWA access to Geolocation
2) Inform the user that location tracking will be performed even when the
move away from the App.
3) Allow tracking to be discoverable via status bar or other

For more details on the planned implementation please see: -
https://github.com/w3c/ServiceWorker/issues/745#issuecomment-304168724

Some initial ideas: -

   1. User permission must be explicitly granted before GPS is accessible.
   2. While GPS is being watched, even in background, the circles/ripples
   icon cue is visible to user on the device.
   3. The underlying Service Worker architecture mandates the use of
   secure/authenticated httpS communication.
   4. httpS is now also mandated for GPS access

I personally think the above is enough, but for the sake of argument, does
anyone have thoughts on how access may be further governed?

   1. Only permit background/service-worker GPS access if the Web App is
   installed/home-screened?
   2. If a single GPS permission will cover both background and foreground
   access, then put a link on the toast to the Faustian details?
   3. Use a new icon, perhaps an eye or a doughnutted version of the
   current GPS ripples? Pulse the icon?
   4. When phone/device wakes an/or UWA is foregrounded a notification
   should inform user that tracking continued while App was not visible.


Anything else?

Re: [whatwg] Firebase Cloud Messaging (FCM) blows the W3C/IETF Success Prevention Depts out of the water!

[Richard Maher]

Hopefully the quoting below is legible: -

-Original Message-
From: Richard's Hotmail [mailto:maher...@hotmail.com] 
Sent: Wednesday, April 19, 2017 7:09 AM
To: 'whatwg@lists.whatwg.org'
Subject: Re: [whatwg] Firebase Cloud Messaging (FCM) blows the W3C/IETF
Success Prevention Depts out of the water!

> On Tue, Mar 28, 2017 at 9:30 AM, Roger
Hågensen <rh_wha...@skuldwyrm.no> wrote:
>> On 2017-03-27 05:50, Richard Maher wrote:
>> Broadcast Messaging and Topic Based subscription is now available to your
>> WebApp just like native Apps thanks to FCM.
>>
>> https://firebase.google.com/docs/cloud-messaging/js/send-multiple
>>
>> I am absolutely ecstatic about this, as we all should be, and equally
>> grateful to FCM for having managed to bypass the recalcitrance and sheer
>> bloody-mindedness of spec-authors to provide functionality that everyone
>> outside the ivory-towers was begging for.
>>
>> I thought WhatWG was set up to challenge the delusional elite a la mode
de
>> HTML5? Why the silence?
> 
> Maybe because this is a Google API and cloud service rather than a 
> web standard added to Chrome, Firefox, Edge, Safari, 
> Opera, Vivaldi etc? Unless I'm missing some important detail here!

Yes it is a Google API. A browser agnostic Google API that runs on Chrome,
Firefox, Samsung, soon to be Opera, and Edge. Anything that runs
ServiceWorker and Push. While I would’ve preferred W3C/IETF to see the sense
and requirement for Topic-based subscriptions and broadcast messaging, the
Firebase API is from the same stable as other ubiquitous APIs such as Google
Maps? Analytics? Google+ logon.

>> Anyway rejoice and be glad as Native Apps have one less stick to beat us
>> over the head with. And you Firefox fans are no longer stuck with
Mozilla's
>> third-rate AutoPush!
>
> I'm not aware of anything called autopush, is this another cloud API?
> Or do you mean https://developer.mozilla.org/en/docs/Web/API/Push_API ?

See:  - https://mozilla-push-service.readthedocs.io/en/latest/
 

>> Now if we can only get background geolocation with ServiceWorkers nothing
>> can stop WebApps: -
>> https://github.com/w3c/ServiceWorker/issues/745

> Considering I'm coding both native and "HTML5" based "apps" 
> there is far more that needs to be improved.
> There is no way to reliably know how much LocalStorage or 
> IndexDB space the web app has, trying to access or list files 
> locally in a folder is not possible, something as simple as a 
> editable soundboard can't be made if it's run locally (via file:
protocol).
> While Xinput is supported, DirectInput is not and there is a lot of 
> controllers out there that are not Xinput.
> Trying to save a file locally is a pain, you have to simulate a download. 
> Loading a audio file manipulating it and saving it again is not the 
> same as with a native app, instead you end up with a duplicate file 
> in the download folder instead of the original files folder.

If there is a requirement for Oracle 12G on a mobile phone then I’m sure
they will build it. In the meantime the fundamental service/retail-delivery
shift that the world is currently experiencing is crying out for background
geolocation Uber, Dominos, GrindR, Facebook, Deliveroo, Maps/Navigation and
on and on. 

Please let WebApps compete with Native Apps! 

> There is a difference between a Webapp that supports offline 
> and a offline "HTML5" app.
>
> Using NWN.js and Electron turns it into a native app anyway, 
> ideally one should not have to do this, at least not for "simple" apps.
>> PS. The cognoscente are once more assembling on April 4-5 for a Japanese
>> junket on ServiceWorkers to yet again wax bollocks on "offline first" :-(
>
> What is wrong with offline first? If you have a Ohms law 
> calculator and your internet is down there is no reason why it 
> should not still work if it was saved in the cache or even locally 
> as a .html file and opened in the browser while the internet is down.

If ifs and ands were pots and pans there’d be no worker for new age
travelers.
 
> It's rare for the internet to be down for long periods of time, 
> but usually it goes down wen it's the least convenient and not 
> having apps break and still work is important in those cases.

I don’t believe network reliability is an issue for the vast majority of the
money-spending public.

>> Please lobby the names that can be found in the hall of shame here: -
>> https://github.com/w3c/ServiceWorker/issues/1053

> Hall of shame? It sounds like you have some form of personal agenda here.

My agenda is to get Background Geolocation out there on Web Apps before it
is too late. Service Worker extensibility seems ideal to me but I don't
really care how it is done as long as it gets done.

Cheers Richard

Re: [whatwg] Firebase Cloud Messaging (FCM) blows the W3C/IETF Success Prevention Depts out of the water!

[Richard Maher]

On Tue, Mar 28, 2017 at 9:30 AM, Roger Hågensen 
<rh_wha...@skuldwyrm.no<mailto:rh_wha...@skuldwyrm.no>> wrote:

On 2017-03-27 05:50, Richard Maher wrote:
Broadcast Messaging and Topic Based subscription is now available to your
WebApp just like native Apps thanks to FCM.

https://firebase.google.com/docs/cloud-messaging/js/send-multiple

I am absolutely ecstatic about this, as we all should be, and equally
grateful to FCM for having managed to bypass the recalcitrance and sheer
bloody-mindedness of spec-authors to provide functionality that everyone
outside the ivory-towers was begging for.

I thought WhatWG was set up to challenge the delusional elite a la mode de
HTML5? Why the silence?

Maybe because this is a Google API and cloud service rather than a web standard 
added to Chrome, Firefox, Edge, Safari, Opera, Vivaldi etc? Unless I'm missing 
some important detail here!

Yes it is a Google API. A browser agnostic Google API that runs on Chrome, 
Firefox, Samsung, soon to be Opera, and Edge. Anything that runs ServiceWorker 
and Push. While I would’ve preferred W3C/IETF to see the sense and requirement 
for Topic-based subscriptions and broadcast messaging, the Firebase API is from 
the same stable as other ubiquitous APIs such as Google Maps? Analytics? 
Google+ logon.

Anyway rejoice and be glad as Native Apps have one less stick to beat us
over the head with. And you Firefox fans are no longer stuck with Mozilla's
third-rate AutoPush!

I'm not aware of anything called autopush, is this another cloud API?
Or do you mean https://developer.mozilla.org/en/docs/Web/API/Push_API ?

See:  - https://mozilla-push-service.readthedocs.io/en/latest/


Now if we can only get background geolocation with ServiceWorkers nothing
can stop WebApps: -
https://github.com/w3c/ServiceWorker/issues/745

Considering I'm coding both native and "HTML5" based "apps" there is far more 
that needs to be improved.
There is no way to reliably know how much LocalStorage or IndexDB space the web 
app has, trying to access or list files locally in a folder is not possible, 
something as simple as a editable soundboard can't be made if it's run locally 
(via file: protocol).
While Xinput is supported, DirectInput is not and there is a lot of controllers 
out there that are not Xinput.
Trying to save a file locally is a pain, you have to simulate a download. 
Loading a audio file manipulating it and saving it again is not the same as 
with a native app, instead you end up with a duplicate file in the download 
folder instead of the original files folder.

If there is a requirement for Oracle 12G on a mobile phone and then I’m sure 
they will build it. In the meantime the fundamental service/retail-delivery 
shift that the world is currently experiencing is crying out for background 
geolocation Uber, Dominos, GrindR, Facebook, Deliveroo, Maps/Navigation and on 
and on.

Please let WebApps compete with Native Apps!

There is a difference between a Webapp that supports offline and a offline 
"HTML5" app.

Using NWN.js and Electron turns it into a native app anyway, ideally one should 
not have to do this, at least not for "simple" apps.
PS. The cognoscente are once more assembling on April 4-5 for a Japanese
junket on ServiceWorkers to yet again wax bollocks on "offline first" :-(

What is wrong with offline first? If you have a Ohms law calculator and your 
internet is down there is no reason why it should not still work if it was 
saved in the cache or even locally as a .html file and opened in the browser 
while the internet is down.

If ifs and ands were pots and pans there’d be no worker for new age travelers.

It's rare for the internet to be down for long periods of time, but usually it 
goes down wen it's the least convenient and not having apps break and still 
work is important in those cases.

I don’t believe network reliability is an issue for the vast majority of the 
money-spending public.

Please lobby the names that can be found in the hall of shame here: -
https://github.com/w3c/ServiceWorker/issues/1053

Hall of shame? It sounds like you have some form of personal agenda here.

My agenda is to get Background Geolocation out there on Web Apps before it is 
too late. Service Worker extensibility seems ideal to me but I don't really 
care how it is done as long as it gets done.

Cheers Richard

Re: [whatwg] Accessing local files with JavaScript portably and securely

[Richard Maher]

>  If the browser vendors feel like this is out of scope for their product, 
> then spending the (quite extensive)
>  effort to design a solution will be wasted. I > wouldn't want anyone on this 
> list to feel their time is wasted.

I also do not like to see W3C’s valuable time continually wasted on specifying 
functionality that has expressly been dismissed by major browser vendors. For 
example: -

https://www.w3.org/TR/geofencing/
  and
https://bugs.chromium.org/p/chromium/issues/detail?id=383125#c46

> Indeed not! I should hope nobody would feel that way. The WHATWG is a venue
> that is open to anyone willing to take part in relevant technical debate.

Then please stop censoring my posts or manufacturing chicken-and-egg 
pre-requisites for topics you are not interested in.


From: Ian Hickson [mailto:i...@hixie.ch]
Sent: Wednesday, April 19, 2017 6:47 AM
To: Richard Maher; wha...@whatwg.org
Subject: Re: [whatwg] Accessing local files with JavaScript portably and 
securely

On Tue, Apr 18, 2017 at 3:36 PM Richard Maher 
<maher...@hotmail.com<mailto:maher...@hotmail.com>> wrote:
> The main thing that seems to be missing from this thread is any commitment
> from any browser vendors to actually support any changes in this space.

It has been my experience that browser vendors, more often than not, require at 
least a (proposed) standard before they will consider implementing a requested 
feature.

That's a different question. I was saying we should make sure the browser 
vendors care about this space at all. Requesting a specific feature be 
implemented comes much later, after use case collection and API design stages.

If the browser vendors feel like this is out of scope for their product, then 
spending the (quite extensive) effort to design a solution will be wasted. I 
wouldn't want anyone on this list to feel their time is wasted.


I would certainly not seek to stifle debate or censor someone else from having 
their say.

Indeed not! I should hope nobody would feel that way. The WHATWG is a venue 
that is open to anyone willing to take part in relevant technical debate.

--

--
Ian Hickson



Re: [whatwg] Accessing local files with JavaScript portably and securely

[Richard Maher]

> The main thing that seems to be missing from this thread is any commitment
> from any browser vendors to actually support any changes in this space.

It has been my experience that browser vendors, more often than not, require at 
least a (proposed) standard before they will consider implementing a requested 
feature.

While I personally find the inordinate level of effort and debate that goes 
into off-line first functionality frustrating, I would certainly not seek to 
stifle debate or censor someone else from having their say.

Background geolocation can work via service workers for fleet-management even 
in the complete absence of an instantiated UA and definitely requires the WWW 
to function but then I’m all for Web functionality and network connectivity and 
IoT and so on.

[whatwg] Firebase Cloud Messaging (FCM) blows the W3C/IETF Success Prevention Depts out of the water!

[Richard Maher]

Broadcast Messaging and Topic Based subscription is now available to your
WebApp just like native Apps thanks to FCM.

https://firebase.google.com/docs/cloud-messaging/js/send-multiple

I am absolutely ecstatic about this, as we all should be, and equally
grateful to FCM for having managed to bypass the recalcitrance and sheer
bloody-mindedness of spec-authors to provide functionality that everyone
outside the ivory-towers was begging for.

I thought WhatWG was set up to challenge the delusional elite a la mode de
HTML5? Why the silence?

Anyway rejoice and be glad as Native Apps have one less stick to beat us
over the head with. And you Firefox fans are no longer stuck with Mozilla's
third-rate AutoPush!

Now if we can only get background geolocation with ServiceWorkers nothing
can stop WebApps: -
https://github.com/w3c/ServiceWorker/issues/745

Happy Days!!!

Cheers Richard Maher

PS. The cognoscente are once more assembling on April 4-5 for a Japanese
junket on ServiceWorkers to yet again wax bollocks on "offline first" :-(

Please lobby the names that can be found in the hall of shame here: -
https://github.com/w3c/ServiceWorker/issues/1053

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

[Richard Maher]

Thanks Michael. So to be safe one should use Edge? Who'd have thunk it?

Anyone tested Michael's example on FireFox or Safari?

It does look like Chrome is the driver of rel=noopener. Does the credential
API https://w3c.github.io/webappsec-credential-management/ rely on this
flaw?

On Fri, Dec 2, 2016 at 11:44 AM, Michael A. Peters <mpet...@domblogger.net>
wrote:

> If window.opener() did not work cross-domain then as far as I can tell
> that would be secure.
>
>
> On 12/01/2016 07:23 PM, Richard Maher wrote:
>
>> I see what you're saying Michael and also agree it's serious. Would I be
>> correct in thinking that MS Edge solves the problem by not returning
>> window.opener cross-domain? Is the UA not a logical and uniform place for
>> this?
>>
>> BTW I've also experienced the CitHub topic-closure nazis many times :-(
>>
>>
>> On Fri, Dec 2, 2016 at 10:42 AM, Michael A. Peters <
>> mpet...@domblogger.net>
>> wrote:
>>
>> Well if it was done as a header, I suppose it could be added as a
>>> http-equiv meta tag for those who want to.
>>>
>>> Header is the easiest solution to make sure it is applied everywhere
>>> without question. It could even be added at the front-end proxy to cover
>>> numerous web applications on many domains at once.
>>>
>>> And I know this is conspiracy theory, but that's why I think there is
>>> such
>>> resistance to it.
>>>
>>> Since the flaw is required for OAuth to work, companies invested in OAuth
>>> and that profit from OAuth solutions don't want sites behind proxies that
>>> would break OAuth and don't want webmasters to understand they have to
>>> reduce security in order to implement an OAuth solution.
>>>
>>> That's just a suspicion of mine, but I can't think of any other logical
>>> reason as to why a node attribute was chosen as the solution, and why
>>> there
>>> is such resistance to doing it the right way with a header. To me it just
>>> doesn't make sense.
>>>
>>>
>>> On 12/01/2016 05:45 PM, Zac Spitzer wrote:
>>>
>>> how about rather than requiring this on every  why not support a base
>>>> tag directive
>>>> for the whole document i.e. , similar to >>> target="_blank">?
>>>>
>>>> On Fri, Dec 2, 2016 at 12:39 PM, Domenic Denicola <d...@domenic.me> wrote:
>>>>
>>>> From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Ian
>>>>
>>>>> Hickson
>>>>>
>>>>> I believe that's a bit of an overstatement. There are certainly risks
>>>>>
>>>>>>
>>>>>> involved in window.opener (they're briefly discussed in the spec
>>>>> itself),
>>>>> but it doesn't remove the origin checks.
>>>>>
>>>>> This is the crucial point.
>>>>>
>>>>> Whenever you are discussing a supposed security issue, you need to make
>>>>> clear what the threat model is. That is:
>>>>>
>>>>> - What would be the impact on the victim if the security hole is taken
>>>>> advantage of?
>>>>> - Is this something we are trying to prevent on the web platform?
>>>>>
>>>>> In this case, the impact on the victim (a user of a web browser) is
>>>>> that
>>>>> they could click a link from page A to page B, which opens in a new tab
>>>>> (tab B). Then, tab A could be navigated to a new URL, instead of
>>>>> staying
>>>>> on
>>>>> page A.
>>>>>
>>>>> This is not a big impact. Notably, page B is not able to read any of
>>>>> the
>>>>> content of page A, which might be sensitive. Page B is not able to
>>>>> interfere with the operation of any of page B's scripts. And crucially,
>>>>> when page B navigates tab A to another page, the URL bar of tab A
>>>>> changes
>>>>> to indicate that.
>>>>>
>>>>> There is no desired security guarantee on the platform that we want to
>>>>> prevent pages from directing users to "bad" sites. We count on users
>>>>> inspecting the URL bar to understand what page they are interacting
>>>>> with
>>>>> in
>>>>> a given tab.
>>>>>
>>>>> So, while it might be a bit surprising that suddenly tab A is
>>>>> navigating
>>>>> somewhere else, there is no security issue here, and users are not
>>>>> endangered in any way---at least, not in any more danger than they
>>>>> already
>>>>> are from browsing the web without looking at their URL bar to see where
>>>>> they've ended up at.
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>

Re: [whatwg] window.opener security issues (Was: WhatWG is broken)

[Richard Maher]

I see what you're saying Michael and also agree it's serious. Would I be
correct in thinking that MS Edge solves the problem by not returning
window.opener cross-domain? Is the UA not a logical and uniform place for
this?

BTW I've also experienced the CitHub topic-closure nazis many times :-(


On Fri, Dec 2, 2016 at 10:42 AM, Michael A. Peters 
wrote:

> Well if it was done as a header, I suppose it could be added as a
> http-equiv meta tag for those who want to.
>
> Header is the easiest solution to make sure it is applied everywhere
> without question. It could even be added at the front-end proxy to cover
> numerous web applications on many domains at once.
>
> And I know this is conspiracy theory, but that's why I think there is such
> resistance to it.
>
> Since the flaw is required for OAuth to work, companies invested in OAuth
> and that profit from OAuth solutions don't want sites behind proxies that
> would break OAuth and don't want webmasters to understand they have to
> reduce security in order to implement an OAuth solution.
>
> That's just a suspicion of mine, but I can't think of any other logical
> reason as to why a node attribute was chosen as the solution, and why there
> is such resistance to doing it the right way with a header. To me it just
> doesn't make sense.
>
>
> On 12/01/2016 05:45 PM, Zac Spitzer wrote:
>
>> how about rather than requiring this on every  why not support a base
>> tag directive
>> for the whole document i.e. , similar to > target="_blank">?
>>
>> On Fri, Dec 2, 2016 at 12:39 PM, Domenic Denicola  wrote:
>>
>> From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Ian
>>> Hickson
>>>
>>> I believe that's a bit of an overstatement. There are certainly risks

>>> involved in window.opener (they're briefly discussed in the spec itself),
>>> but it doesn't remove the origin checks.
>>>
>>> This is the crucial point.
>>>
>>> Whenever you are discussing a supposed security issue, you need to make
>>> clear what the threat model is. That is:
>>>
>>> - What would be the impact on the victim if the security hole is taken
>>> advantage of?
>>> - Is this something we are trying to prevent on the web platform?
>>>
>>> In this case, the impact on the victim (a user of a web browser) is that
>>> they could click a link from page A to page B, which opens in a new tab
>>> (tab B). Then, tab A could be navigated to a new URL, instead of staying
>>> on
>>> page A.
>>>
>>> This is not a big impact. Notably, page B is not able to read any of the
>>> content of page A, which might be sensitive. Page B is not able to
>>> interfere with the operation of any of page B's scripts. And crucially,
>>> when page B navigates tab A to another page, the URL bar of tab A changes
>>> to indicate that.
>>>
>>> There is no desired security guarantee on the platform that we want to
>>> prevent pages from directing users to "bad" sites. We count on users
>>> inspecting the URL bar to understand what page they are interacting with
>>> in
>>> a given tab.
>>>
>>> So, while it might be a bit surprising that suddenly tab A is navigating
>>> somewhere else, there is no security issue here, and users are not
>>> endangered in any way---at least, not in any more danger than they
>>> already
>>> are from browsing the web without looking at their URL bar to see where
>>> they've ended up at.
>>>
>>>
>>
>>
>>
>

Re: [whatwg] Background Geolocation for Progressive Web-Apps

[Richard Maher]

On Fri, Dec 2, 2016 at 9:41 AM, Karl Dubost <k...@la-grange.net> wrote:

>
> Le 2 déc. 2016 à 08:53, Richard Maher <mahe...@googlemail.com> a écrit :
> > The main goal of background geolocation reporting
>
> Previous related threads:
> https://groups.google.com/forum/#!topic/mozilla.dev.
> geolocation/D5UXf-N3JfU

Chalk and Chees. But I do want wakelock functionality as well.

>
> https://lists.w3.org/Archives/Public/public-geolocation/2016Feb/0016.html

Since then the Geofencing API has died

>
> https://lists.w3.org/Archives/Public/public-geolocation/2016Feb/0017.html

Well worth reading

>
> https://lists.w3.org/Archives/Public/public-geolocation/2016Feb/0010.html

 Yep

>
> https://groups.google.com/forum/#!topic/mozilla.dev.
> geolocation/UXkd3Tz1GPc

Unrelated. I managed to get Chrome's implementation of the GeoFence API
canned and a wakeLock is not battery friendly and not secure except for
constantly foreground APPs such as navigation.

[whatwg] Background Geolocation for Progressive Web-Apps

[Richard Maher]

Cor, steady on Hixie, it wasn’t me yelling that “WHATWG is broken”. All I’m
trying to do is get someone (not me) to start development on a solution for
background geolocation in HTML5 Web Apps. Sorry if my post was in/pas
apropos.



> all that matters is the quality of arguments and data presented



Excellent news!  Here I go: -



Secure, user-sanctioned geolocation collection is currently unavailable for

HTML5 Web-Apps when they are not running or in the foreground. This leaves

the browser hosted applications incapable of competing with Native Apps on

an even playing field.



The main goal of background geolocation reporting is to allow all web-apps, but

in particular, Gaming, Social-Network, and Fleet-Management Apps, to

continue to function even if the device has gone to sleep or another App is

in the foreground.



Additional goals are:



   -  Power-Saving. By using the existing ServiceWorker paradigm and flexible

   throttle/filter on which geolocation movements are "interesting".

-Single-process (Google Play etc) to monitor all geolocation reports for

   all Apps before deciding if ServiceWorker(s) need to be instantiated.

-Unlike Mozilla's current implementation, stalkers, estranged spouses,

   and marketeers will no longer be allowed to track users covertly.



My suggested solution: -



serviceWorkerRegistration.travelManager.subscribe({options. . .})



The "options" contain "filter" that can specify such things as minimum
distance traveled, minimum reporting interval, accuracy, maximum loiter
interval and so on. Once an "interesting" geolocation position change has
been obtained a ServiceWorker can be instantiated to process the event in
the same way that Push Notifications are handled today.


This is where it plugs-in: -

https://w3c.github.io/ServiceWorker/#extensibility



The following diagram that illustrates how shimlessly typical user
movements map to the ServiceWorker paradigm: -





Elapsed Time: 



User Travelling:  PPP Stopped P-PP



Service Worker 1: --



Service Worker 2: 



Now I find that argument compelling! How about you?



Cheers Richard

Re: [whatwg] Push API and Endpoints

[Richard Maher]

Personally. I'd vote for endpoint mapping to be done in the Message Service
with Topic based subscriptions. Just like GCM/GCM, Amazon, Apple, and
Microsoft support.

[whatwg] Intent to implement: Background Geolocation for Progressive Web-Apps

[Richard Maher]

Contact emails

mahe...@gmail.com


*Summary*

Secure, user-sanctioned geolocation collection is currently unavailable for
HTML5 Web-Apps when they are not running or in the foreground. This leaves
the browser hosted applications incapable of competing with Native Apps on
an even playing field.


The main goal of background geolocation reporting is to all web-apps, but
in particular, Gaming, Social-Network, and Fleet-Management Apps, to
continue to function even if the device has gone to sleep or another App is
in the foreground.


Additional goals are:

   -

   Power-Saving. By using the existing ServiceWorker paradigm and flexible
   throttle/filter on which geolocation movements are "interesting".
   -

   Single-process (Google Play etc) to monitor all geolocation reports for
   all Apps before deciding if ServiceWorker(s) need to be instantiated.
   -

   Unlike Mozilla's current implementation, stalkers, estranged spouses,
   and marketeers will no longer be allowed to track users covertly.


Here is design overview document:

https://sites.google.com/a/chromium.org/dev/developers/design-documents/
ServiceWorker/TravelManagerEvent

Ongoing technical constraints

None. See https://w3c.github.io/ServiceWorker/#extensibility
Tracking bug
There is currently no top level bug.

*FOR MORE PLEASE SEE: - *

https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/kDq4t93zbpA