Security considerations in explainer

[ewilligers]

Describe a number of threats that have been identified,
and possible approaches to mitigate them.

Issue #1 remains open for further security discussions.

[mgiuca]

Since this is the cornerstone of our mitigations, maybe go into some more detail here perhaps with a UX mock.

[marcoscaceres]

Agree... this is the challenging bit. How do you explain what is going on here to a user and what the implications of getting pwned are? Or, alternatively, is this made scary enough that a user doesn't start filling out random things.

The concern is that if you can send the right bits of information you can attack the hardware, rewrite firmware, and if you are motivated enough, destroy the hardware.

I'm thinking of this small attack:
https://www.cybersecurity-insiders.com/cyber-attack-launched-on-150000-printers-working-worldwide/

But is a web page can trick a user to ssh into some server on a company network, that's a pretty scary prospect.

[mgiuca]

Right, but what we should always keep in mind is that (as with all of these "scary" web APIs), we are not adding unheard of abilities to a completely safe vacuum; we are competing with native applications which have much less restricted network access.

If we can replace native apps that need network access with web apps that do so in a highly restrictive model (such as requiring explicit user entry of the destination host), that should severely limit the ability of those apps to conduct large-scale scanning.

[ewilligers]

We don't want to give users the incorrect impression they would be safer installing a native app.

Mock added: preview

[AdrianCX]

Local apps may be safer:

• I can firewall local apps from accessing only required services.

• Local apps cannot be updated on the fly as are web pages.

• I have local apps signed by key I trust from a repository I trust.

• I can use strace to log what a local app does.

Is there a plan to provide these as well?

[marcoscaceres]

Agree... this is the challenging bit. How do you explain what is going on here to a user and what the implications of getting pwned are? Or, alternatively, is this made scary enough that a user doesn't start filling out random things.

The concern is that if you can send the right bits of information you can attack the hardware, rewrite firmware, and if you are motivated enough, destroy the hardware.

I'm thinking of this small attack:
https://www.cybersecurity-insiders.com/cyber-attack-launched-on-150000-printers-working-worldwide/

But is a web page can trick a user to ssh into some server on a company network, that's a pretty scary prospect.

[marcoscaceres]

There is still a threat where a third-party is injected via a first-party context, like via any <script> tag that loads a script from a CDN for instance. Then the third-party script could silently gain access to a socket once the user grants permission.

[mgiuca]

Isn't there some mechanism that can restrict access to APIs from third-party scripts?

[ewilligers]

I don't think that is a MITM attack.

If I understand correctly, third-party script loaded in <script> tags with Subresource Integrity has the same security properties as any external script a web developer might copy/paste into their project repo, or list in their npm dependencies or similar.

Use of unscrutinized third party script falls into a different class of threats, like disgruntled developer risk, that affect all powerful APIs and are not specific to the web platform.

[marcoscaceres]

Isn't there some mechanism that can restrict access to APIs from third-party scripts?

No, unfortunately.

Use of unscrutinized third party script falls into a different class of threats, like disgruntled developer risk, that affect all powerful APIs and are not specific to the web platform.

Right, I think this is where we get into the fundamental philosophical differences in our communities: Mozilla folks are hesitant to add anything to the platform that allow a "disgruntled developer" level attack. Why we have no BlueTooth, MIDI, etc. etc... so, in a sense they are specific to the web platform in as far as Mozilla (and Apple) have not shipped these kinds of APIs for this reason.

That's not to say it's a show stopper - but it gives us a point at which we can ask, "what's this thing trying to do?"

[marcoscaceres]

This still allows for passive scans. Maybe this would be in control of the connection UI... the user could then hit a "retry" button, rather than the web page doing it.

[ewilligers]

The UI would have a control like "[ ] Allow future connections", both to support resilience when network difficulties occur and to avoid permissions fatigue when a given web app is used frequently.

In an industrial context, a dedicated machine might be configured with a web app that connects to specific devices. Requiring user interaction after each device power cycle or other disconnection would be unfortunate.