[gruez]

>Secure context: This feature is available only in secure contexts (HTTPS), in some or all supporting browsers.

What's the point of this? I understand why you might want this for APIs that expose private user information, but this just performs some computation. You could do the same thing with a js library or webassembly. Is this just to punish http sites?

[imajoredinecon]

There might be more to the privacy characteristics of an API like this than meets the eye. For instance, if a user grants camera permissions scoped to http://insecure.website in order to scan a QR code and get it detected, it might be surprising to the user that on-path attackers would be able to see the user’s camera snaps. Making the API work in a degraded mode in insecure contexts (e.g. by disabling particularly privacy-sensitive data sources) might be a plausible alternative, but at this point it’s arguably cleaner and less risky to just make the interface HTTPS-only in order to avoid making developers and users reason through these nuances.

[xg15]

I don't get it. The privacy risk in there is from getUserMedia(), which is already (correctly) https-only. There is no privacy risk coming from the barcode API itself.

[dblohm7]

Basically, yes. Browser vendors have had an agreement for some time now to only expose new APIs in secure contexts in order to encourage HTTPS adoption.

[makeitdouble]

I am in agreement with wyager, this feature looks like it could be heavily beneficial to a shipping company's internal web app for instance, or other applications that could be running completely isolated from the global network (or running on the machine itself for that matter).

Forcing https in these applications is a waste of time and money for orthogonal purposes. I guess it could be seen as a cost of dev. for any web based application from now on, but it's sad to me to see the barrier to entry get higher for these reasons.

[jupp0r]

If it's cheaper for you to run an http than an https server then you are holding it wrong.

[arjvik]

Internal domains, where getting a certificate to client devices is painful

[jonhohle]

I've had the same issue, but mostly for home lab type stuff. Even if you set up an internal CA and all the trappings, you still have a root cert problem. For consumer devices without easy access to certificate stores, it gets complicated fast.

Maybe the state of the art has changed since the last time I looked, but it would be really nice to have something as easy as Lets Encrypt for private tools while at the same time not exposing internal network details.

[cloudwizard]

It works in secure contexts. internal domains with .localhost name are considered secure.

https://developer.mozilla.org/en-US/docs/Web/Security/Secure... Locally-delivered resources such as those with http://127.0.0.1 URLs, http://localhost and http://*.localhost URLs (e.g. http://dev.whatever.localhost/), and file:// URLs are also considered to have been delivered securely.

[xg15]

Yes, because they are hardwired to point to your own machine. You cannot use those to deploy an internal webapp.

[hhh]

External wildcard cert? Maybe it’s different in smaller shops, but it’s just as easy for me to get an internal cert as it is to get an external cert. Only annoying part about our shop is a hard req fit EV certs, so no ACME.

[pests]

You can use a public CA like LetsEncrypt then. Exposes you to the certificate log but you should be secured already anyways. Just have to use the DNS challenge (unless you wanna poke a hole for certbot) to grab it

[tedunangst]

And people wonder why ioshit devices are all so cloud dependent. I just want my microwave to talk to my refrigerator (or whatever). But they have to use https, because. And the cert has to expire every 90 days, because. So now I provision a kitchen full of stuff with AWS creds so they can respond to DNS challenges to get those certs.

So much simpler for everything to revert to client only mode and route all messages through a server 3000 miles away. Until they pull the plug and nothing works at all.

[makeitdouble]

Looking at guides for LetsEncrypt on internal IPs/domains, it seems to be as painful as creating and managing your own CA: https://geontech.com/using-letsencrypt-ssl-internally/

[makeitdouble]

> you are holding it wrong.

For those whooshed by the reference, it's about the iPhone's antenna design flaw that Jobs poopooed on stage, to silently get it fixed on the next version.

It seems we're agreeing it's an actual issue that would merit to be fixed.

[wyager]

I'm not sure I feel great about gating feature A behind completely unrelated feature B just because manufacturers like feature B. Even if feature B is concretely pretty good (which is debatable for https as it exists now), this seems bad on principle.

[jorl17]

I'm interested: why do you think it is debatable if HTTPS is "concretely pretty good" as it exists now?

[Nextgrid]

It's not always necessary. Think fully offline networks that can't/won't use a CA anyway, or networks where physical/machine access is the intended layer of security (a web server running on localhost).

In these scenarios a self-signed certificate will rarely improve security because most users will click through the warning anyway in case of an MITM attack.

[unqueued]

Users should not have to rely on the network being isolated for security.

Even when I have an offline network, I still use SSH whenever possible.

Yes, I don't benefit from initial verification, but I pin the certificate from then on.

I don't think that the current "all or nothing" paradigm that we use with SSL in browsers makes any sense.

I have been really disappointed over the last few years deploying network connected devices and trying to make their services available in a secure way.

It is not really possible for ipcams, routers, etc to offer services in HTTPS in a semi-online network. There should be a kind of 'encrypted but unverified' mode.

Even the worst failure mode is no worse than a plaintext connection.

[Nextgrid]

Let’s say I sell a physical device that allows you to use a browser as its UI. You just plug an Ethernet cable and point your browser to its web server.

Security is done by physical access. Anything else is just extra complexity and points of failure, and if an attacker can get physical access to the LAN cable, he can just as well walk to the machine directly and change the settings on the control panel.

HTTPS, with its current UX, would be a net negative in this case.

[pornel]

Browsers make an exception for localhost and treat it as a secure context.

It's also possible to get a certificate from a CA using any public IP address, and then reuse that cert for LAN. Certs are bound to domain names, not IP addresses.

[jonhohle]

Why should an org expose details of private infrastructure publicly? For anyone with more than a few internal tools this becomes untenable or unreasonable quickly and sharing a wildcard cert has diminishing returns as its shared between apps, teams, etc.

[judge2020]

If it helps, it really doesn’t care what certificate the page it signed with, whether that be localhost, Mozilla CA participants, or maybe even a future CA fork for Russia if that happens. Plaintext HTTP is just not advisable even on a private network when some inline network device like LAN turtle could be passively exfiltrating traffic.

[bhawks]

The browser security model is trivially defeated without the usage of https. IT is not an orthogonal or unrelated feature.

Making all new API development available only when content is delivered via a mechanism that provides the foundation for the rest of web security is good engineering practice.

[eternityforest]

I'm not a fan of the whole secure context separation thing. A lot of cool P2P stuff is impossible because a service worker can't access an HTTP server, which would be very useful for web sites to talk to IoT devices.

If there was something sensitive in front of my camera, I wouldn't give any random site permission anyway.

File system access should definitely be secure only, the rest might not need it.

Of course if Mozilla actually did FlyWeb we could almost totally deprecate HTTP except for some public legacy sites.

[chiph]

pdf417 barcodes are commonly used on US driver's licenses, and contain private information like the person's address, height, eye color, full name, etc. For the API to do its work in detecting a valid barcode, it needs to be able to read the entire barcode to compute a checksum/checkdigit. Which means it has to read the data.

[gruez]

But this API doesn't allow access to the camera. The caller is responsible for passing in an image to be parsed. Saying it needs to be blocked for that reason is like saying parseInt() should be blocked.