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

[Jeffrey Yasskin]

Please follow the WHATWG code of conduct when posting to this list:
https://wiki.whatwg.org/wiki/Code_of_Conduct. In particular, I believe this
message violates:

   - Please be kind and courteous. There's no need to be mean or rude.
   - Respect that people have differences of opinion and that every design
   or implementation choice carries a trade-off and numerous costs. There is
   seldom a right answer.
   - You shall not insult, demean or harass anyone. We interpret the term
   "harassment" as including the definition in the Citizen Code of Conduct
   ; if you have any lack of clarity
   about what might be included in that concept, please read their definition.
   In particular, we don't tolerate behavior that excludes people in socially
   marginalized groups.


Thanks,
Jeffrey

On Tue, Apr 18, 2017 at 4:09 PM, Richard Maher  wrote:

> On Tue, Mar 28, 2017 at 9:30 AM, Roger Hågensen  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 

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

[duanyao]

在 2017年04月19日 02:23, Ian Hickson 写道:
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.


Yes, and I had been pessimistic about that even before I join this thread.

Actually I join the discussion mainly to see whether there are some 
convincing reasons for web standards and browsers to ignore local files.

It is more than welcome if browser vendors would like to comment on this.

Something already mentioned:

* Local files are against the philosophy of the Web.
  Then the problem is what is the philosophy of the Web exactly and why 
-- seems still unclear.


* Accessing local files from local files with JavaScript is insecure.
  Some solutions (including mine) are discussed and I think this is 
solvable. Please comment if anyone think otherwise.


* Accessing local files is not portable.
  I think with some best practices in mind a local web app can be quite 
portable. I'd like to see counterexamples

  if anyone has some.

* A local http server could be an alternative.
  Problems of a local http server have been discussed in detail.

* Electron/NW.js etc. could be alternatives.
  It is overkill to ship a small web app with a large runtime, 
especially when the advanced desktop features are not needed.
  The enoumous man power devoted to Electron/NW.js and similar projects 
is a signal that local web app is relevant.


Something not mentioned here, just my guess:

* Local web app is against the business model of current Internet.
  Please consider users first.

* Cloud is the future, local files will become irrelevant.
  Seems premature, and there are people who feel unconfortable to 
cloudize all personal data and workflow.


I would recommend the following steps for anyone hoping to push 
changes to Web specifications on this topic:


- Approach Web browser vendors privately, to see if they are 
interested in changing their behaviour in this space.


I've no such private link.



- If you find interest, collect up the use cases that you want to 
address, and post them to this list for discussion.


- Collect the input on use cases and try to design a solution that 
fits all the important use cases, then send an an e-mail to this list 
proposing a basic design.


These have been a lot of discussion on that in this thread. Do you think 
writing a more formal document would be helpful?




Cheers,
--
Ian Hickson
--

--
Ian Hickson



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  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 
> 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 
> 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

[Ian Hickson]

On Tue, Apr 18, 2017 at 3:36 PM Richard Maher  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.

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

[Ian Hickson]

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. I
would recommend the following steps for anyone hoping to push changes to
Web specifications on this topic:

- Approach Web browser vendors privately, to see if they are interested in
changing their behaviour in this space.

- If you find interest, collect up the use cases that you want to address,
and post them to this list for discussion.

- Collect the input on use cases and try to design a solution that fits all
the important use cases, then send an an e-mail to this list proposing a
basic design.

Cheers,
-- 
Ian Hickson
-- 

-- 
Ian Hickson



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

[duanyao]

在 2017年04月18日 19:27, Ashley Sheridan 写道:


On 18 April 2017 12:18:57 BST, duanyao  wrote:

在 2017年04月18日 18:52, Ashley Sheridan 写道:

Maybe no. "files" is a generic word, so if you make every

"xxx_files/"

folders magical, it's quite possible that there are folders happen

to

ends with "_files" but are not intented to be local web apps. If you
require a `xxx.html` to make "xxx_files/" magical, it is a little
awkward and confusing for muli-page app.

This is why I propose a new (and unlikely already used) pattern
`xxx_webrun/` for more powerful muli-page app, and limit

`xxx_files/`

to
single page app.

In single page app case, it would be more common that `test.html`

gets

`test_files\page{2|3}.html` via XHR and renders the latter in place,
instead of navigating to it.
So the latter don't need to access `test_files\config.json`

themselves.

*any* magic behavior is a sure-fire sign that something is wrong(TM)

Maybe. But there are occasions where magic is unavoidable. E.g. how to
infer the MIME type of a file? filename extension? magic numbers? all
are magic.

If the barrier is not high enough, name it `xxx__webrun__/`.

But when you're talking about security, which we are, relying on magic anything 
is potentially disastrous.

You mention mime types and file extensions, both of which are not safe to rely 
on for anything related to security, hence there being entire libraries and 
frameworks to attempt to determine and test a files real type (windows still 
fails abysmally in this area though).

Just relying on magic filenames *will* fail. Consider the scenario where a file 
is accidentally copied over the original entry html. Now it's associated with 
the wrong directory of assets and other 'linked' files. This new html entry 
point file could easily be an exploited file, looking to grab whatever data is 
being held locally on your machine.


If a local web app is really critical, it may be digitally signed to 
prevent tampering.
For example, signatures and certifications can be placed in 
`foo_files/META-INF/` or `foo_webrun/META-INF/`(like a signed jar).
A browser can detect change to any file within the web app when loading 
and stops to run.


Signing with a self-signed cert should be enough to detect accident 
damage, and browsers can do this every time it saves a web page.






Thanks,
Ash

Thanks,
Ash

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

[duanyao]

在 2017年04月18日 19:27, Ashley Sheridan 写道:


On 18 April 2017 12:18:57 BST, duanyao  wrote:

在 2017年04月18日 18:52, Ashley Sheridan 写道:

Maybe no. "files" is a generic word, so if you make every

"xxx_files/"

folders magical, it's quite possible that there are folders happen

to

ends with "_files" but are not intented to be local web apps. If you
require a `xxx.html` to make "xxx_files/" magical, it is a little
awkward and confusing for muli-page app.

This is why I propose a new (and unlikely already used) pattern
`xxx_webrun/` for more powerful muli-page app, and limit

`xxx_files/`

to
single page app.

In single page app case, it would be more common that `test.html`

gets

`test_files\page{2|3}.html` via XHR and renders the latter in place,
instead of navigating to it.
So the latter don't need to access `test_files\config.json`

themselves.

*any* magic behavior is a sure-fire sign that something is wrong(TM)

Maybe. But there are occasions where magic is unavoidable. E.g. how to
infer the MIME type of a file? filename extension? magic numbers? all
are magic.

If the barrier is not high enough, name it `xxx__webrun__/`.

But when you're talking about security, which we are, relying on magic anything 
is potentially disastrous.

You mention mime types and file extensions, both of which are not safe to rely 
on for anything related to security, hence there being entire libraries and 
frameworks to attempt to determine and test a files real type (windows still 
fails abysmally in this area though).
Those libraries and frameworks *will* fail because it is entirely 
possible that a file is conformant to multiple formats simultaneously.

Also the methodology use by those libraries and frameworks is magic.



Just relying on magic filenames *will* fail. Consider the scenario where a file 
is accidentally copied over the original entry html. Now it's associated with 
the wrong directory of assets and other 'linked' files. This new html entry 
point file could easily be an exploited file, looking to grab whatever data is 
being held locally on your machine.
Sure it is possible, but usually the damage is limited because the entry 
file can only access a limited folder `XXX_files`. By
accidentally overriding a html file, you already cause a data loss in 
the first place.


Thanks,
Ash

Thanks,
Ash

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

[Ashley Sheridan]

On 18 April 2017 12:18:57 BST, duanyao  wrote:
>在 2017年04月18日 18:52, Ashley Sheridan 写道:
>>
>>> Maybe no. "files" is a generic word, so if you make every
>"xxx_files/"
>>> folders magical, it's quite possible that there are folders happen
>to
>>> ends with "_files" but are not intented to be local web apps. If you
>>> require a `xxx.html` to make "xxx_files/" magical, it is a little
>>> awkward and confusing for muli-page app.
>>>
>>> This is why I propose a new (and unlikely already used) pattern
>>> `xxx_webrun/` for more powerful muli-page app, and limit
>`xxx_files/`
>>> to
>>> single page app.
>>>
>>> In single page app case, it would be more common that `test.html`
>gets
>>> `test_files\page{2|3}.html` via XHR and renders the latter in place,
>>> instead of navigating to it.
>>> So the latter don't need to access `test_files\config.json`
>themselves.
>> *any* magic behavior is a sure-fire sign that something is wrong(TM)
>Maybe. But there are occasions where magic is unavoidable. E.g. how to 
>infer the MIME type of a file? filename extension? magic numbers? all 
>are magic.
>
>If the barrier is not high enough, name it `xxx__webrun__/`.

But when you're talking about security, which we are, relying on magic anything 
is potentially disastrous.

You mention mime types and file extensions, both of which are not safe to rely 
on for anything related to security, hence there being entire libraries and 
frameworks to attempt to determine and test a files real type (windows still 
fails abysmally in this area though). 

Just relying on magic filenames *will* fail. Consider the scenario where a file 
is accidentally copied over the original entry html. Now it's associated with 
the wrong directory of assets and other 'linked' files. This new html entry 
point file could easily be an exploited file, looking to grab whatever data is 
being held locally on your machine. 

>
>>
>>
>> Thanks,
>> Ash

Thanks,
Ash

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

[duanyao]

在 2017年04月18日 18:52, Ashley Sheridan 写道:



Maybe no. "files" is a generic word, so if you make every "xxx_files/"
folders magical, it's quite possible that there are folders happen to
ends with "_files" but are not intented to be local web apps. If you
require a `xxx.html` to make "xxx_files/" magical, it is a little
awkward and confusing for muli-page app.

This is why I propose a new (and unlikely already used) pattern
`xxx_webrun/` for more powerful muli-page app, and limit `xxx_files/`
to
single page app.

In single page app case, it would be more common that `test.html` gets
`test_files\page{2|3}.html` via XHR and renders the latter in place,
instead of navigating to it.
So the latter don't need to access `test_files\config.json` themselves.

*any* magic behavior is a sure-fire sign that something is wrong(TM)
Maybe. But there are occasions where magic is unavoidable. E.g. how to 
infer the MIME type of a file? filename extension? magic numbers? all 
are magic.


If the barrier is not high enough, name it `xxx__webrun__/`.




Thanks,
Ash

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

[Ashley Sheridan]

>Maybe no. "files" is a generic word, so if you make every "xxx_files/" 
>folders magical, it's quite possible that there are folders happen to 
>ends with "_files" but are not intented to be local web apps. If you 
>require a `xxx.html` to make "xxx_files/" magical, it is a little 
>awkward and confusing for muli-page app.
>
>This is why I propose a new (and unlikely already used) pattern 
>`xxx_webrun/` for more powerful muli-page app, and limit `xxx_files/`
>to 
>single page app.
>
>In single page app case, it would be more common that `test.html` gets 
>`test_files\page{2|3}.html` via XHR and renders the latter in place, 
>instead of navigating to it.
>So the latter don't need to access `test_files\config.json` themselves.

*any* magic behavior is a sure-fire sign that something is wrong(TM)


Thanks,
Ash

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

[duanyao]

在 2017年04月18日 16:08, Anne van Kesteren 写道:

On Tue, Apr 18, 2017 at 9:57 AM, Roger Hågensen  wrote:

Searching Google for "offline webapp discussion group" turns up
https://www.w3.org/wiki/Offline_web_applications_workshop
and that's sadly from 2011.

There is https://www.w3.org/TR/offline-webapps/

Right, those are about making applications distributed over HTTPS work
when the user is not connected. That idea doesn't necessitate file
URLs and we're still working towards that ideal with Fetch, HTML, and
Service Workers. All browsers seem on board with that general idea
too, which is great.
Offline webapp is great, but I'd say that offline webapp is "an online 
web app that can work offline temporarily",
not really a local web app. If the entity operating an offline webapp 
goes out of service permanently, the webapp
will stop to work soon. This is one of the reasones why local web app is 
still relevant.

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

[duanyao]

在 2017年04月18日 16:09, Roger Hågensen 写道:

On 2017-04-17 15:22, duanyao wrote:

This can handle multipage fine as well.
Anything in the folder test.html_files is considered sandboxed under
test.html

The problem is, what if users open `test_files\page2.html`or
`test_files\page3.html`directly? Can they access 
`test_files\config.json`?

This is to be solve by the "muli-page application" convention. By the
way, the name of the directory is usually `foo_files`, not
`foo.html_files`.


Good point. But why would a user do that when the entry point is the 
test.html?
The user may bookmark it and access it later on; the tab maybe restored 
from a previous browser session;

the user may open it from the histroy list, and so on.



In this case the browser could just fallback to default behavior for 
local html files.

Agree.


Alternatively the browser could have some logic that knows that this 
is a page under the test folder which is the sandbox for test.html


Also your example of "test_files\page3.html" and 
"test_files\config.json" ofcourse page3.html could access it, just 
like it could access config.js if not for CORS on XHR and local files.
Maybe no. "files" is a generic word, so if you make every "xxx_files/" 
folders magical, it's quite possible that there are folders happen to 
ends with "_files" but are not intented to be local web apps. If you 
require a `xxx.html` to make "xxx_files/" magical, it is a little 
awkward and confusing for muli-page app.


This is why I propose a new (and unlikely already used) pattern 
`xxx_webrun/` for more powerful muli-page app, and limit `xxx_files/` to 
single page app.


In single page app case, it would be more common that `test.html` gets 
`test_files\page{2|3}.html` via XHR and renders the latter in place, 
instead of navigating to it.

So the latter don't need to access `test_files\config.json` themselves.



Actually a lot of the issue here is XHR (and fetch) not being possible 
for local web pages.


The only reason I suggested using the same naming convention for the 
sandbox folder is that (at least on Windows) Explorer deletes both the 
html and folder something users are familiar with. Though I'm sure 
Microsoft could add support for the same to another folder naming 
convention, I can't see that being backported to Windows 8.1/8/7.
`xxx_webrun/` convention doesn't need OSes' support, just browsers'; and 
you just delete that folder to delete the app completely.





I just checked what naming Chrome does and it uses the page title. I
can't recall what the other browsers do. And adds _files to it.

Chrome can be configured to ask for location when saving a page, then
you can name it as you will.
The "xxx_files" convention was introduced by IE or Netscape long ago,
and other browsers just follow it.
...

I have not tested how editing/adding to this folder affect things,
deleting the html file also deletes the folder (at least on Windows
10, and I seem to recall on Windows 7 as well).

There is no magic link between `foo.html` and `foo_files/`, this is just
a trick of Windows Explorer. You can change things by hand in that
directory as you will.


I just confirmed that. just creating a empty .html file and a same 
named folder with _Files at the end does "link" them in Explorer.
Is this unique to Windows or does other platforms do the 
same/something similar?


Probably just Windows Explorer. At least Nautilus file manager on linux 
doesn't do the trick.

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

[Anne van Kesteren]

On Tue, Apr 18, 2017 at 10:25 AM, Roger Hågensen  wrote:
> On 2017-04-18 10:08, Anne van Kesteren wrote:
>> Right, those are about making applications distributed over HTTPS work
>> when the user is not connected. That idea doesn't necessitate file
>> URLs and we're still working towards that ideal with Fetch, HTML, and
>> Service Workers. All browsers seem on board with that general idea
>> too, which is great.
>
> But being able to access files added to a "subfolder" of said offline app
> won't be possible I assume?

I'm not sure what that means. But you can still interact with the app
and do things with it, including storing data if the app allows such a
thing.


> Maybe just adding the ability to ask the user if accessing this or that file
> or this and that folder for indexing (and accessing the files within) would
> be better.

There's  and https://wicg.github.io/entries-api/.


> Does the WHATWG and W3C meet/have a common group at all? (for the editors)
> So that cross-group messes can be handled/avoided?

Well, we talk now and then and that has resulted in some improvements,
but it's also still ongoing and some within the W3C actively try to
make it worse (e.g., DOM is being forked again without a good reason).
So, nothing good thus far.


-- 
https://annevankesteren.nl/

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

[Roger Hågensen]

On 2017-04-18 10:08, Anne van Kesteren wrote:

There is https://www.w3.org/TR/offline-webapps/


Right, those are about making applications distributed over HTTPS work
when the user is not connected. That idea doesn't necessitate file
URLs and we're still working towards that ideal with Fetch, HTML, and
Service Workers. All browsers seem on board with that general idea
too, which is great.


But being able to access files added to a "subfolder" of said offline 
app won't be possible I assume?


Maybe just adding the ability to ask the user if accessing this or that 
file or this and that folder for indexing (and accessing the files 
within) would be better.


A different open file requester would be needed, and a requester for 
open folder + access contents of folder would be needed. That way the 
file paths can be retrieve an used with , , Fetch and so on.



...they're more independent than that. (And we don't really
appreciate any copying that takes place. It's a lot less as of late,
but it still happens, as documented in e.g.,
https://annevankesteren.nl/2016/01/film-at-11 and
https://wiki.whatwg.org/wiki/Fork_tracking.)


Ok that is a bit of an asshat move. I've got nothing against forking but 
there is obviously a right and a wrong way to do that.
Does the WHATWG and W3C meet/have a common group at all? (for the 
editors) So that cross-group messes can be handled/avoided?


--
Unless specified otherwise, anything I write publicly is considered 
Public Domain (CC0).

Roger Hågensen,
Freelancer, Norway.

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

[Roger Hågensen]

On 2017-04-17 15:22, duanyao wrote:

This can handle multipage fine as well.
Anything in the folder test.html_files is considered sandboxed under
test.html

The problem is, what if users open `test_files\page2.html`or
`test_files\page3.html`directly? Can they access `test_files\config.json`?
This is to be solve by the "muli-page application" convention. By the
way, the name of the directory is usually `foo_files`, not
`foo.html_files`.


Good point. But why would a user do that when the entry point is the 
test.html?


In this case the browser could just fallback to default behavior for 
local html files.


Alternatively the browser could have some logic that knows that this is 
a page under the test folder which is the sandbox for test.html


Also your example of "test_files\page3.html" and 
"test_files\config.json" ofcourse page3.html could access it, just like 
it could access config.js if not for CORS on XHR and local files.


Actually a lot of the issue here is XHR (and fetch) not being possible 
for local web pages.


The only reason I suggested using the same naming convention for the 
sandbox folder is that (at least on Windows) Explorer deletes both the 
html and folder something users are familiar with. Though I'm sure 
Microsoft could add support for the same to another folder naming 
convention, I can't see that being backported to Windows 8.1/8/7.



I just checked what naming Chrome does and it uses the page title. I
can't recall what the other browsers do. And adds _files to it.

Chrome can be configured to ask for location when saving a page, then
you can name it as you will.
The "xxx_files" convention was introduced by IE or Netscape long ago,
and other browsers just follow it.
...

I have not tested how editing/adding to this folder affect things,
deleting the html file also deletes the folder (at least on Windows
10, and I seem to recall on Windows 7 as well).

There is no magic link between `foo.html` and `foo_files/`, this is just
a trick of Windows Explorer. You can change things by hand in that
directory as you will.


I just confirmed that. just creating a empty .html file and a same named 
folder with _Files at the end does "link" them in Explorer.
Is this unique to Windows or does other platforms do the same/something 
similar?


--
Unless specified otherwise, anything I write publicly is considered 
Public Domain (CC0).

Roger Hågensen,
Freelancer, Norway.

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

[Anne van Kesteren]

On Tue, Apr 18, 2017 at 9:57 AM, Roger Hågensen  wrote:
> Searching Google for "offline webapp discussion group" turns up
> https://www.w3.org/wiki/Offline_web_applications_workshop
> and that's sadly from 2011.
>
> There is https://www.w3.org/TR/offline-webapps/

Right, those are about making applications distributed over HTTPS work
when the user is not connected. That idea doesn't necessitate file
URLs and we're still working towards that ideal with Fetch, HTML, and
Service Workers. All browsers seem on board with that general idea
too, which is great.


> Now I know that WHATWG and W3 Working Group is not the same thing,
> but if W3C thinks that offline apps are part of the web but WHATWG does not
> then that creates a huge chasm as WHATWG would then ignore all offline
> stuff.

The WHATWG collaborates with a W3C group on service workers. WHATWG
ends up being responsible for the underpinnings defined in Fetch and
HTML.


> I always assumed that WHATWG was a fast track variant of W3C. Brainstorming
> stuff, getting it tested/used in browsers then seeing what sticks to the
> wall and once things become stable the W3C will hammer it in stone. Is that
> assumption wrong?

A bit, they're more independent than that. (And we don't really
appreciate any copying that takes place. It's a lot less as of late,
but it still happens, as documented in e.g.,
https://annevankesteren.nl/2016/01/film-at-11 and
https://wiki.whatwg.org/wiki/Fork_tracking.)


-- 
https://annevankesteren.nl/

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

[Roger Hågensen]

On 2017-04-17 19:19, duanyao wrote:

There are always incompatibilities
between browsers, and even once standardized feature can be
deprecated/removed in future, e.g. `window.showModalDialog()`,
`` and ``.

This happens rarely and when it happens it's a very considered
decision involving lots of people. It's usually related to complexity,
lack of use, and security.

Sure. Proprietary OSes don't change thier core API in incompatibe way
for no good reason, too.

I don't expect a local web app tested on major OSes today would stop to
work tomorrow due to a filesystem API change.


It's probably more likely that a online web app will stop functioning 
than a local/offline web app. When it's local there is only the browser 
and OS involved. Online you have the 
OS+Browser+Router+ISP+Proxies+Webserver(+cache)+possibly Serverside 
scripting.



Arguing about the manifest/statement of WHATWG and what is within the 
scope of WHATWG may be irrelevant.


Think of the end user first. If a end user "saves" a online webapp they 
expect it to work offline too. And in my eyes there is no reason why it 
should not.


Now I have not tested this yet but if a html page has links to other 
html pages or files one would assume those files are also saved.


Likewise if a user drags a file from a folder to say a soundbank app and 
then they close it and open it the next day only to find it empty again 
as paths can't be stored they'd think the app is broken (or that html 
apps sucks).



This can be partially fixed by making the user typed in file paths 
manually, but this is very use unfriendly.


That a html "app" can work online, offline, and locally, is one of the 
biggest benefits it has over other languages/program environments.


Microsoft already does something similar with it's UWP apps which can be 
html and javascript based.


Personally I like the idea of a app that has it's source open, issues 
could technically be fixed without having to get the source code (as the 
app is the source code) nor a need to recompile it with the exact same 
developer setup/compiler/IDE. It's also relatively easy to inspect.


Searching Google for "offline webapp discussion group" turns up
https://www.w3.org/wiki/Offline_web_applications_workshop
and that's sadly from 2011.

There is https://www.w3.org/TR/offline-webapps/

Now I know that WHATWG and W3 Working Group is not the same thing,
but if W3C thinks that offline apps are part of the web but WHATWG does 
not then that creates a huge chasm as WHATWG would then ignore all 
offline stuff.


I always assumed that WHATWG was a fast track variant of W3C. 
Brainstorming stuff, getting it tested/used in browsers then seeing what 
sticks to the wall and once things become stable the W3C will hammer it 
in stone. Is that assumption wrong?



--
Unless specified otherwise, anything I write publicly is considered 
Public Domain (CC0).

Roger Hågensen,
Freelancer, Norway.