Cannot relax CSP for inline JavaScript

[bitwyse]

Hello

I am using a Chromium-based navigator to test some web pages.

I have many pages with up to 50 thumbnail photos on each. Each thumbnail is a link which opens a new window with the full-size photo:
<a onClick="newwind('../photos/photo.jpg');"><img src="../thumb/photo.jpg"></a>

This works perfectly with ALL navigators except the Chromium family - the CSP refuses all inline JS and the onClick doesn't fire.

So I put
Header set Content-Security-Policy "script-src 'self' 'unsafe-inline'"
in the .htaccess and this is correctly returned in the HTTP headers from my Apache server, but the onClick still doesn't work.

(Also tried a <meta... > in the page header.)

What am I doing wrong/not doing?

Thanks, regards

PS - threre are more than 1000 of these links - I can't replace all the onClicks with event listeners...

[PhistucK]

1. If you remove the Content-Security-Policy header altogether, does it work?

2. You could add an external JavaScript to the page that goes over all of the links and converts the inline event handler to addEventListener. Ugly, but probably works.

☆PhistucK

--
--
Chromium Discussion mailing list: chromium...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-discuss

---
You received this message because you are subscribed to the Google Groups "Chromium-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-discuss+unsubscribe@chromium.org.

[bitwyse]

Hi

Le jeudi 20 juillet 2017 16:02:06 UTC+2, PhistucK a écrit :

1. If you remove the Content-Security-Policy header altogether, does it work?

No - I didn't use it until I discovered the problem with Chromium recently.
(I first started using this new window opening method in a site created 16 years ago! - since then in 6 others: never had any problems).
The doc says that this header should work...
 

2. You could add an external JavaScript to the page that goes over all of the links and converts the inline event handler to addEventListener. Ugly, but probably works.

Hummm. I just ran a grep to check: there are 1012 onClick handlers in 47 files.
I'd have to add a different ID to each of the anchors on the same page.
And what might be the effect of having 40 - 50 eventListeners ticking away?

☆Phistuc

[PhistucK]

1. Inline scripts/event listeners are allowed in pages that have not declared a content security policy, so your Chromium based product might be adding some content security policy enforcement that Chrome does not, in which case, there is not much this group can do to help you.

Do you happen to be using a Chrome application/extension (an installed CRX/unpacked) to host those pages (they have an implicit content security policy)?

2. 40 - 50 listeners should not be a problem (inline event listeners and addEventListener have similar costs anyway).

☆PhistucK

--

[bitwyse]

Thanks PhistucK

Le jeudi 20 juillet 2017 17:39:48 UTC+2, PhistucK a écrit :

1. Inline scripts/event listeners are allowed in pages that have not declared a content security policy, so your Chromium based product might be adding some content security policy enforcement that Chrome does not, in which case, there is not much this group can do to help you.

My "product" is Comodo Dragon.
I posted the same problem in their own support forum but nobody has answered.
 

Do you happen to be using a Chrome application/extension (an installed CRX/unpacked) to host those pages (they have an implicit content security policy)?

No, it's just plain HTML pages on an ordinary Apache server (nothing to do with Chromium).

2. 40 - 50 listeners should not be a problem (inline event listeners and addEventListener have similar costs anyway).

 

 OK - but that would still make me a lot of work.

I can use a grep to change the "OnClick" in all my HTML files but have to figure out a way to create and insert unique ID's at the same time (I could do it easily in JavaScript on each page but it wouldn't be allowed).
The eventListeners have got to be attached to a documentGetElementById and they need an argument to know what to to (which photo to display) - that could be an array ['ID' <-> URL de la photo].
Wouldn't need the anchors - the event listener could just watch the thumbnail.

It would be so much simpler to simply allow the inline onClicks - I will never have the time to do the rest and will just finish par diplaying an alert to Chrome users that it imposes limits that prevent using the site: so use a different browser - 'any'...).

As a programmer of the "old school" I always worked on the principle that "all sites should work correctly wirh all the navigators in current use".
But nowadays no-on sticks to that; if anything doesn't work they just tell you to try another one. So if Chromium doesn't respect the standards I'm going to do the same.

BTW - I tried and quickly abandoned Chrome(ium) for development because of their ridiculous refusal to fix the fille:// cookies BUG.
I develop all my sites on my hard disk before ever uploading them to Internet. Can't waste time with their other personal idiosynchrosies as well.
(The command line option "--enable-file-cookies" does NOT work).

[Torne (Richard Coles)]

Chromium *does* allow inline onclicks by default. Content-Security-Policy is an opt-in feature: if you don't ask to have a more restrictive policy, then you shouldn't get one. If you do, then either Comodo have changed something in their version, or there's a bug in the code that needs to be fixed, or you're not doing what you think you're doing. This is not "Chromium not respecting the standards" and being rude to people who are trying to help isn't constructive.

[bitwyse]

Le jeudi 20 juillet 2017 20:54:23 UTC+2, Torne (Richard Coles) a écrit :

Chromium *does* allow inline onclicks by default. Content-Security-Policy is an opt-in feature: if you don't ask to have a more restrictive policy, then you shouldn't get one.

Chromium? - I did try it, had problems, and then decided that Dragon was potentially less invasive.
Until then I wasn't even aware that it was necessary to change Content Security Policy - I had nothing at all concerning that.
My pages just stopped working - without any error messages.
 

If you do, then either Comodo have changed something in their version, or there's a bug in the code that needs to be fixed,

Maybe. I haven't had an answer from them.
 

or you're not doing what you think you're doing.

Well - that's exactly the question I asked!
 

This is not "Chromium not respecting the standards"

Google Chrome has its own ideas and won't listen to people who don't agree. I got rid of it quickly and replace it on my clients' machines if I can.
But I seem to have the same problems with Chomium and Dragon

and being rude to people who are trying to help isn't constructive.

I thanked PhistucK who tried to help for his suggestions - and criticised Google developers who refuse to listen to users' opinions or conform to normal practices.
It's just like Microsoft - Internet Explorer has never respected WWW standards and causes immense headaches for those who want to program sites accessible to everybody.
It was a bit calmer for a while: IE (depending on the version however) or all the rest...
Now Chrome(ium) has suddenly introduced new complications - and according to what you say it appears also that we are going to have to take into account whether it's Google Chrome, Chromium, or Dragon..
 

[Torne (Richard Coles)]

On Thu, 20 Jul 2017 at 15:36 bitwyse <del...@zoho.com> wrote:

Le jeudi 20 juillet 2017 20:54:23 UTC+2, Torne (Richard Coles) a écrit :

Chromium *does* allow inline onclicks by default. Content-Security-Policy is an opt-in feature: if you don't ask to have a more restrictive policy, then you shouldn't get one.

Chromium? - I did try it, had problems, and then decided that Dragon was potentially less invasive.
Until then I wasn't even aware that it was necessary to change Content Security Policy - I had nothing at all concerning that.

It's not necessary to change content security policy. The default policy if you don't set one (per the standards, and in all major browsers including Chromium/Chrome) is "everything is allowed".

So, if inline script is being blocked, then either you actually *are* specifying a content security policy that says inline script should be blocked without realising it, or you're using a browser that's changed this for some reason which would break huge numbers of websites, or there's a bug in the code that affects the particular situation you're in.

When we say "Chromium" here we're often referring to the entire family of chromium-based browsers, since they inherit all the chromium code and so behave exactly the same as Chromium unless that particular browser has chosen to change a particular thing. It's *possible* Comodo does something different here but I don't think it's very likely, because it would break huge numbers of websites (many sites do not specify a content security policy, and so changing the default policy would be very disruptive).

 

My pages just stopped working - without any error messages.
 

If you do, then either Comodo have changed something in their version, or there's a bug in the code that needs to be fixed,

Maybe. I haven't had an answer from them.

The quickest way to check if it's an issue with Comodo or not is to compare it to the behaviour in Chromium or Google Chrome, which definitely have the right behaviour in normal cases - it's not clear from your messages whether you've tried this already or not. If it fails the same way in Chrome/Chromium then the most likely explanation is that something is actually setting a content security policy in your configuration somehow without you realising it, but it may also be a bug in the chromium code. If you've already tried, then can you tell us whether it worked in those or not, and apologies if you already said but I can't see it anywhere.

 

 

or you're not doing what you think you're doing.

Well - that's exactly the question I asked!
 

This is not "Chromium not respecting the standards"

Google Chrome has its own ideas and won't listen to people who don't agree. I got rid of it quickly and replace it on my clients' machines if I can.

This doesn't seem to have anything to do with what I was saying. It sounded like you were assuming that this was some deliberate decision by Chromium to change behaviour in a way that breaks existing pages and doesn't match the standards (if you weren't, then I'm sorry for misinterpreting you) - this is what I was responding to: we haven't intentionally changed anything here, there shouldn't be any change for existing sites, and we should be doing exactly as the standard says.

 

But I seem to have the same problems with Chomium and Dragon

and being rude to people who are trying to help isn't constructive.

I thanked PhistucK who tried to help for his suggestions - and criticised Google developers who refuse to listen to users' opinions or conform to normal practices.
It's just like Microsoft - Internet Explorer has never respected WWW standards and causes immense headaches for those who want to program sites accessible to everybody.
It was a bit calmer for a while: IE (depending on the version however) or all the rest...
Now Chrome(ium) has suddenly introduced new complications - and according to what you say it appears also that we are going to have to take into account whether it's Google Chrome, Chromium, or Dragon..
 

--

[bitwyse]

Le jeudi 20 juillet 2017 21:52:15 UTC+2, Torne (Richard Coles) a écrit :

It's not necessary to change content security policy. The default policy if you don't set one (per the standards, and in all major browsers including Chromium/Chrome) is "everything is allowed".

I _did not have ANY_ Content Secutiy Policy defined anywhere.
I was not even aware that inline JavaSvript was a new issue (since the same code had worked  perfectly for 16 years).
(For the sites I work on security is not a concern.)

So, if inline script is being blocked, then either you actually *are* specifying a content security policy that says inline script should be blocked without realising it,

How, where?
 

or you're using a browser that's changed this for some reason which would break huge numbers of websites, or there's a bug in the code that affects the particular situation you're in.

I have four browsers:
 - Seamonkey (for my personal use)
 - FireFox (same engine, but without all the volontary protection/limitaions of the above)
 - Internet Explorer
 - Dragon
The last three are for testing my own HTML pages with differrent engines (I used to use Opera, but got disappointed)

ALL my own pages work fine in all of them except for those I have mentionned which suddenly stopped working in Chrom* browsers (I am almost sure that they worked in Google Chrome before).
 

When we say "Chromium" here we're often referring to the entire family of chromium-based browsers, since they inherit all the chromium code and so behave exactly the same as Chromium unless that particular browser has chosen to change a particular thing.

That is what I assumed...

The quickest way to check if it's an issue with Comodo or not is to compare it to the behaviour in Chromium or Google Chrome, which definitely have the right behaviour in normal cases - it's not clear from your messages whether you've tried this already or not.

See above.
I will try Chromium again.
 

If it fails the same way in Chrome/Chromium then the most likely explanation is that something is actually setting a content security policy in your configuration somehow without you realising it

How, where?
 

This doesn't seem to have anything to do with what I was saying. It sounded like you were assuming that this was some deliberate decision by Chromium to change behaviour in a way that breaks existing pages and doesn't match the standards

Foe example - Google Chrome deliberately decided and has always refused despite many developers' complaints to ban cookies with the file:// protocol (the same restiction applied with Chromium when I tried it). Alll other browsers accept them.
Now most of us develop sites on our hard disks before uploading them to Internet (we haven't all got ultra-high speed connexions - I just came back from a client who has a satellite connexion at 512kBit/s, mine is a bit better - 2Mbit/s).
That means that - even if it has some useful developer tools (but no better than Firefox) - it is unuseable for site development, therefore not particularly interesting for programmers - we just use it to see how others view our sites on line. And that is how I discovered this bug.


 

[PhistucK]

See my comments inline.

☆PhistucK

On Thu, Jul 20, 2017 at 8:49 PM, bitwyse <del...@zoho.com> wrote:

Thanks PhistucK

Le jeudi 20 juillet 2017 17:39:48 UTC+2, PhistucK a écrit :

1. Inline scripts/event listeners are allowed in pages that have not declared a content security policy, so your Chromium based product might be adding some content security policy enforcement that Chrome does not, in which case, there is not much this group can do to help you.

My "product" is Comodo Dragon.
I posted the same problem in their own support forum but nobody has answered.
 

Do you happen to be using a Chrome application/extension (an installed CRX/unpacked) to host those pages (they have an implicit content security policy)?

No, it's just plain HTML pages on an ordinary Apache server (nothing to do with Chromium).

Can you share the URL so people could debug it?

Alternatively, can you try it with Google Chrome (or Chromium)?

Or even with other browsers, like Firefox?

If the issue reproduces in Firefox as well, it would be more likely that something has changed in your setup than all of the browsers suddenly changing their behavior in this regard. But without reproducing it myself, I cannot tell for sure.

 

2. 40 - 50 listeners should not be a problem (inline event listeners and addEventListener have similar costs anyway).

 

 OK - but that would still make me a lot of work.

I can use a grep to change the "OnClick" in all my HTML files but have to figure out a way to create and insert unique ID's at the same time (I could do it easily in JavaScript on each page but it wouldn't be allowed).
The eventListeners have got to be attached to a documentGetElementById and they need an argument to know what to to (which photo to display) - that could be an array ['ID' <-> URL de la photo].
Wouldn't need the anchors - the event listener could just watch the thumbnail.

Actually, with my suggestions, you will not have to grep anything. Just include a simple single JavaScript file in all of the HTML files that goes over any element with an onclick attribute and adds an event listener using addEventListener and the content of the attribute. It is fully automated and should only take a few minutes.​

 

It would be so much simpler to simply allow the inline onClicks - I will never have the time to do the rest and will just finish par diplaying an alert to Chrome users that it imposes limits that prevent using the site: so use a different browser - 'any'...).

​I agree that it should work, but you either want a quick solution​ (applying a fix to your pages) or a full solution (fix a bug in Chromium, assuming it is a bug in Chromium). The former was suggested to you above and the latter needs a URL that reproduces the issue so it could be debugged.

 

As a programmer of the "old school" I always worked on the principle that "all sites should work correctly wirh all the navigators in current use".

​That is, indeed, a good way to live and in recent years, have been more true, thanks to a lot of work by the various browser vendors.​

 

But nowadays no-on sticks to that; if anything doesn't work they just tell you to try another one. So if Chromium doesn't respect the standards I'm going to do the same.

I would not go that far - browsers have been converging more and more in favor of compatibility with the web and interoperability with each other. Sometimes browsers have bugs and in order to resolve the issue (temporarily or not) quickly, another browser will be suggested. Reporting the issue will benefit the whole world and is preferred, obviously.

While Chromium respects a lot of standards, it has bugs, just like any other software, but the team is always trying to fix those bugs even before they ship to users. Sometimes they fail, sometimes it takes longer and sometimes they just do not know they broke something until someone comes up with a reproduction that usually turns out to be an edge case they have not thought about. :)​

 

BTW - I tried and quickly abandoned Chrome(ium) for development because of their ridiculous refusal to fix the fille:// cookies BUG.
I develop all my sites on my hard disk before ever uploading them to Internet. Can't waste time with their other personal idiosynchrosies as well.
(The command line option "--enable-file-cookies" does NOT work).

​You insistence on using file:// URLs instead of a small standalone run-without-any-installation static server does not make a lot of sense to me, frankly​, but you are entitled to your own opinion, obviously. :) file:// URL cookies were used for malicious purposes (as far as I understand) and so were dropped. Security trumps convenience for developers, that is just the way it is. file:// URLs, while perhaps convenient, have limitations and restrictions (other than cookies - and always had those restrictions) that makes testing them unlike testing HTTP(S) URLs and you better find those differences at the beginning of your development rather than at the end of it, but that might just be my opinion. ;)

[PhistucK]

See my comments inline.

☆PhistucK

On Thu, Jul 20, 2017 at 11:31 PM, bitwyse <del...@zoho.com> wrote:

Le jeudi 20 juillet 2017 21:52:15 UTC+2, Torne (Richard Coles) a écrit :

It's not necessary to change content security policy. The default policy if you don't set one (per the standards, and in all major browsers including Chromium/Chrome) is "everything is allowed".

I _did not have ANY_ Content Secutiy Policy defined anywhere.

​Then it might be a Comodo, or a Chromium issue. Help us reproduce it, please, by providing a URL.

​

 

I was not even aware that inline JavaSvript was a new issue (since the same code had worked  perfectly for 16 years).
(For the sites I work on security is not a concern.)

​It is not an issue at all, unless there i​s a bug somewhere in the browser that accidentally prevents inline scripts.

While inline scripts are not a best practice for years already, they are totally allowed.

 

So, if inline script is being blocked, then either you actually *are* specifying a content security policy that says inline script should be blocked without realising it,

How, where?

We cannot tell you without debugging.​

 

 

or you're using a browser that's changed this for some reason which would break huge numbers of websites, or there's a bug in the code that affects the particular situation you're in.

I have four browsers:
 - Seamonkey (for my personal use)
 - FireFox (same engine, but without all the volontary protection/limitaions of the above)
 - Internet Explorer
 - Dragon
The last three are for testing my own HTML pages with differrent engines (I used to use Opera, but got disappointed)

ALL my own pages work fine in all of them except for those I have mentionned which suddenly stopped working in Chrom* browsers (I am almost sure that they worked in Google Chrome before).

​Then maybe there is a bug.​

 

 

When we say "Chromium" here we're often referring to the entire family of chromium-based browsers, since they inherit all the chromium code and so behave exactly the same as Chromium unless that particular browser has chosen to change a particular thing.

That is what I assumed...

The quickest way to check if it's an issue with Comodo or not is to compare it to the behaviour in Chromium or Google Chrome, which definitely have the right behaviour in normal cases - it's not clear from your messages whether you've tried this already or not.

See above.
I will try Chromium again.
 

If it fails the same way in Chrome/Chromium then the most likely explanation is that something is actually setting a content security policy in your configuration somehow without you realising it

How, where?

​:)​

 

 

This doesn't seem to have anything to do with what I was saying. It sounded like you were assuming that this was some deliberate decision by Chromium to change behaviour in a way that breaks existing pages and doesn't match the standards

Foe example - Google Chrome deliberately decided and has always refused despite many developers' complaints to ban cookies with the file:// protocol (the same restiction applied with Chromium when I tried it). Alll other browsers accept them.
Now most of us develop sites on our hard disks before uploading them to Internet (we haven't all got ultra-high speed connexions - I just came back from a client who has a satellite connexion at 512kBit/s, mine is a bit better - 2Mbit/s).
That means that - even if it has some useful developer tools (but no better than Firefox) - it is unuseable for site development, therefore not particularly interesting for programmers - we just use it to see how others view our sites on line. And that is how I discovered this bug.

​A static local small server​ would really help you in general. You do not need any network connection for that to work.

 

 

--
--
Chromium Discussion mailing list: chromium...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-discuss

[bitwyse]

Hi PhistucK

Le jeudi 20 juillet 2017 22:35:41 UTC+2, PhistucK a écrit :

Can you share the URL so people could debug it?

Yes, but I'll simplfy it and just publish one page that demonstrates the problem.
 

Alternatively, can you try it with Google Chrome (or Chromium)?

I think it was OK wirh Chrome a while ago (but I didn't keep it for long because of Google's spying policy).
I will try it again with Chromium.
 

Or even with other browsers, like Firefox?

It all still works fine with Firefox, SeaMonkey (same engine) and Internet Explorer.
It never stopped working: I just hadn't tested with Chromium/Dragon for a while (because it had always worked) and was surpised that it no longer did.

If the issue reproduces in Firefox as well, it would be more likely that something has changed in your setup

Nope - no other browsers (I have asked others to test as well).
 

Actually, with my suggestions, you will not have to grep anything. Just include a simple single JavaScript file in all of the HTML files that goes over any element with an onclick attribute and adds an event listener using addEventListener and the content of the attribute. It is fully automated and should only take a few minutes.​

Sorry, I don't understand how can I do this?
None of the elements have any ID to pass to addEventListener
For example (one complete element):
 <td>
   <a onClick="newwind('photo.jpg',langue);"><img src="../thumb/photo.jpg" alt="" width="128" height="96" border="2" style="border-color:#006600;"></a>
 </td>

​I agree that it should work, but you either want a quick solution​ (applying a fix to your pages) or a full solution (fix a bug in Chromium, assuming it is a bug in Chromium). The former was suggested to you above and the latter needs a URL that reproduces the issue so it could be debugged.

 I would apply a simple fix, but I would like the solution proposed ("unsafe-inline") to work!

I would not go that far - browsers have been converging more and more in favor of compatibility with the web and interoperability with each other. Sometimes browsers have bugs and in order to resolve the issue (temporarily or not) quickly, another browser will be suggested.

It happens to me more and more often! - and especially from big Internet-involved companies who have the resources to program and test their sites but just don' t care!

​You insistence on using file:// URLs instead of a small standalone run-without-any-installation static server does not make a lot of sense to me, frankly​, but you are entitled to your own opinion, obviously. :) file:// URL cookies were used for malicious purposes (as far as I understand) and so were dropped.

How? - the explanations that I have read don't make much sense.
There are just two people who have access to my internal (Ethernet) network. Nobody else can read any cookies stored with file://
All cookies except certain authorised permanent are deleted on exiting the navigator.
I really don't see any possible threat - why can't I use the option to allow file cookies?

 

[PhistucK]

See my comments inline.

☆PhistucK

On Fri, Jul 21, 2017 at 12:18 AM, bitwyse <del...@zoho.com> wrote:

Hi PhistucK

Le jeudi 20 juillet 2017 22:35:41 UTC+2, PhistucK a écrit :

Can you share the URL so people could debug it?

Yes, but I'll simplfy it and just publish one page that demonstrates the problem.

​That would be great.

 

 

Alternatively, can you try it with Google Chrome (or Chromium)?

I think it was OK wirh Chrome a while ago (but I didn't keep it for long because of Google's spying policy).
I will try it again with Chromium.
 

Or even with other browsers, like Firefox?

It all still works fine with Firefox, SeaMonkey (same engine) and Internet Explorer.
It never stopped working: I just hadn't tested with Chromium/Dragon for a while (because it had always worked) and was surpised that it no longer did.

If the issue reproduces in Firefox as well, it would be more likely that something has changed in your setup

Nope - no other browsers (I have asked others to test as well).
 

Actually, with my suggestions, you will not have to grep anything. Just include a simple single JavaScript file in all of the HTML files that goes over any element with an onclick attribute and adds an event listener using addEventListener and the content of the attribute. It is fully automated and should only take a few minutes.​

Sorry, I don't understand how can I do this?
None of the elements have any ID to pass to addEventListener
For example (one complete element):
 <td>
   <a onClick="newwind('photo.jpg',langue);"><img src="../thumb/photo.jpg" alt="" width="128" height="96" border="2" style="border-color:#006600;"></a>
 </td>

addEventListener does not need any ID. I had something like that in mind (again, a quick fix, not a best practice at all) -

var elementsWithInlineClickHandlers = ​document.querySelectorAll("[onclick]"), length = elementsWithInlineClickHandlers.length;

for (var i = 0; i < length; i++)

{

 elementsWithInlineClickHandlers[i].addEventListener(

  "click",

  function ()

  {

   eval(this.getAttribute('onclick'));

  });

}

And in case eval is also not supported, you can parse the content of the attribute a bit and run it in a different way.

 

​I agree that it should work, but you either want a quick solution​ (applying a fix to your pages) or a full solution (fix a bug in Chromium, assuming it is a bug in Chromium). The former was suggested to you above and the latter needs a URL that reproduces the issue so it could be debugged.

 I would apply a simple fix, but I would like the solution proposed ("unsafe-inline") to work!

​That makes both of us. :)​

 

I would not go that far - browsers have been converging more and more in favor of compatibility with the web and interoperability with each other. Sometimes browsers have bugs and in order to resolve the issue (temporarily or not) quickly, another browser will be suggested.

It happens to me more and more often! - and especially from big Internet-involved companies who have the resources to program and test their sites but just don' t care! 

​You insistence on using file:// URLs instead of a small standalone run-without-any-installation static server does not make a lot of sense to me, frankly​, but you are entitled to your own opinion, obviously. :) file:// URL cookies were used for malicious purposes (as far as I understand) and so were dropped.

How? - the explanations that I have read don't make much sense.
There are just two people who have access to my internal (Ethernet) network. Nobody else can read any cookies stored with file://

​It is usually not a simple attack. Also, you are probably not the target audience of those attacks, non-techie people are, that download whatever the website tells them to download, click on "Yes" to anything they are asked and open downloaded files without thinking about it.

Browsers are mostly used by simple non-techie users, not by power users. Power users are a small (yet vocal) minority, so browsers must take extraordinary (and annoying to the developer) measures to protect simple non-techie users from themselves. ;)

 

All cookies except certain authorised permanent are deleted on exiting the navigator.
I really don't see any possible threat - why can't I use the option to allow file cookies?

​I am sure there are people here that ​can explain it to you, I am not sure of the exact use case, or exploit that was employed in the wild that lead to that decision, but I trust that the decision was not taken lightly and was probably the right one (especially given that file:// URLs are not used much anyway and a lot of their usage is probably malicious).

[Torne (Richard Coles)]

Given that you weren't intentionally applying a content security policy at all, I'm not surprised that trying to set it to unsafe-inline doesn't work either - because if the CSP was being set/handled correctly then you wouldn't need to set it to anything in the first place. One guess would be that something between the site and your browser is setting a different value, and presumably just overwriting it in the case where you set it explicitly. If you give us a repro case we can check what's going on.

As for file: URLs: it's ill-defined what the scope of cookies would be for a local file, because unlike websites, local files don't have domains. Any choice of how to handle this is either going to be too restrictive to work for all cases someone would like it to work in, or create the possibility of leakage of private data between two unrelated files. Different browsers choose different answers here because the behaviour of file:// is basically outside the scope of web standards. No matter what we choose it's going to be wrong for some case.

There's lots of other web features that also can't work on file: URLs because the origin is ill-defined. I'm not aware of any browser that allows you to precisely define the origin for a file: URL and they all just make different assumptions/guesses which lead to different features working/not working in particular cases.

This does suck but there's no real path to a solution; Chromium has picked a different compromise between bad choices than Firefox, and it may happen that you personally prefer Firefox's choices (or some other browser's), but that doesn't mean Firefox's behaviour is "more right".

The solution recommended to all web developers for many, many years now by the authors of *all* browsers is that you should do your local development using a local webserver, instead of loading pages from file: URLs - not just because some features may not work, but also because things may *work* on a file: URL that won't work on the real site because of the different structure and origin rules.

There are lots of small, trivial webservers you can instantly launch to just serve a specific local directory and its subdirectories as a website - a common recommendation (which only requires that you have Python installed) is "python -m SimpleHTTPServer" which will just start a webserver on http://localhost:8000/ that serves whatever's in the current directory until you Ctrl-C it to stop it.

[PhistucK]

Regarding a lightweight local webserver, I once used https://cesanta.com/binary.html (a 500 KB static web server without any installation, open source or something).

☆PhistucK

[bitwyse]

Thanks to all.
I don't know where you are but it's midnight in France - I'll be back tomorrow!
Regards