1410368 - Ensure that anything blocked by a lack of isSecureContext provides a console warning for developers

Status: NEW

(Core :: DOM: Security, enhancement, P5)

Description

[Jonathan Kingston [:jkt] he/him]

We should ensure that anything is restricted by isSecureContext including any feature in the future always causes a warning in developer tools.

Comment 1

[Anne (:annevk)]

I don't think this is possible as IDL effectively hides the entire API. It would be rather expansive and involve rather low-level changes to not expose a property but still log a warning for it.

Comment 2

[Daniel Veditz [:dveditz]]

Is that true? geolocation only "works" in a secure context now, but afaik we didn't take the API away from insecure pages. If we did wouldn't pages break assuming and referencing a missing API, killing all the script that comes after?

Jonathan: can you spec this out in more detail? Newer features might just be "missing" in insecure context as Anne said so there wouldn't be much to do.

Comment 3

[Jonathan Kingston [:jkt] he/him]

> It would be rather expansive and involve rather low-level changes to not expose a property but still log a warning for it.

I personally think this is worth the effort to allow developers to be informed, 

> but afaik we didn't take the API away from insecure pages.

This is true that we have a custom console that fires when the API is being used.

> Newer features might just be "missing" in insecure context as Anne said so there wouldn't be much to do.

My hope is exactly that we can provide developer some form of tools here when they try to use a restricted API, it doesn't have to be a thrown error or console warning.

Perhaps we can expose for insecure contexts a limited API that prevents enumeration but when it is called directly will trigger the security warning.

So for example:

if ("geolocation" in navigator) {
  // in insecure contexts this wouldn't fire
}

navigator.geolocation.anything;
// Would fire the warning in an insecure context

Also CSS could also provide it's warning symbol with the: "Invalid property value" message when a property is restricted.

I would have to take a look into how we prevent these kinds of behaviors in IDL currently to see if this would be possible. We could also just take the aggressive stance of throwing when !isSecureContext for anything new added to the browser (enumeration and presence checking excluded).

Comment 4

[Anne (:annevk)]

> I personally think this is worth the effort to allow developers to be informed

Have you discussed with DOM/JS peers about the amount of effort this would take? My assumption is that it's far from trivial and a lot of work, energy that's probably better put to use elsewhere given that the end goal is not having insecure contexts.

Daniel, it seems that for some legacy APIs we indeed do expose them. For those we could easily add warnings on getters indeed.

Comment 5

[Jonathan Kingston [:jkt] he/him]

> Have you discussed with DOM/JS peers about the amount of effort this would take?

I spoke to Baku about this and it sounds like we could make the WebIDL generate a map when [SecureContext] is added to an API. The JavaScript error handler can check for the conventional JS errors and additionally fire a secure warning by checking this map.

The issue however is that property access to the undefined feature won't cause an error:

navigator.newThing
// undefined
// We can't catch this and cause an additional error

navigator.newThing.property
// TypeError: navigator.newThing is undefined
// We can catch this and throw an additional error


If we want to do property access this will likely be much harder, but maybe we can ignore that case as it never would error anyway.