Restrict usage to within a secure context.

[cfredric]

This PR restricts usage of the API to within a secure context, and closes #125. As the Storage Access API is intended to address authenticated embeds while protecting user privacy, this change is not expected to be controversial.

• At least two implementers are interested (and none opposed):
  • Chrome
  • Firefox
• Tests are written and can be reviewed and commented upon at:
  • https://crrev.com/c/3991336
• Implementation bugs are filed:
  • Chromium: https://crbug.com/1380155
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1798407
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=247286

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[annevk]

Okay, so the idea is that we continue to expose the API everywhere, but we require a secure context as one of the conditions for a successful invocation.

It would be good to have test coverage for this. I also wonder if there are usage numbers.

[bvandersloot-mozilla]

I think it is worth adding this constraint, even if there is some usage in non-secure contexts. We should sort out #134 first, though, and that is likely to cause merge conflicts

I also think this check should be further up the initial checks here, before the top-level test.

[johannhof]

I agree with Ben that we should move this check up, to reject in all cases, even on (insecure) top-level documents, out of consistency (though this is a weakly held opinion, happy to change my mind if there's a good reason to do it differently).

[johannhof]

(added Firefox as interested in the PR description @bvandersloot-mozilla, lmk if that's inaccurate)

[bvandersloot-mozilla]

(added Firefox as interested in the PR description @bvandersloot-mozilla, lmk if that's inaccurate)

That is accurate. I would have added it myself if I had permission...

[cfredric]

Thanks for the comments - done, moved the secure context check higher up.

Re: tests, happy to add those; just wanted to verify that there was consensus on this first.

[johannhof]

Thank you Chris, this seems fine to me. Let's add tests and file bugs for implementors.

[cfredric]

I've opened bugs for the major implementors (listed in the description above), and have an in-progress CL adding some WPT for this (https://crrev.com/c/3991336).

[johannhof]

Thanks Chris, I think per our checklist this is fine to merge, then.

[drzraf]

As a user, I strongly disagree to restrict this (and many other) JS APIs to particular context (call it "secure").

storage or crypto (to name a few) are fundamental/core programming blocks and this idea of stripping down (= fragmenting) the JS engine is a fondamental/conceptual change regarding the whole language, its abilities and its evolution.

If I have HTTP website (which is perfectly fine in a lot of scenarios), I still expect to rely on a consistent and predictable Javascript engine ; not a freeware/demo/toy-version because, well, someone thought you mustn't use HTTP and found a way to force HTTPS upon you.

This specification (and browsers implementing it) are exceeding a role that falls on developers themselves: They are the ultimate authority about what they do with a language. And users can already choose not to browse HTTP (whose access has already been made de-incentivized).

No one restricted for-loops to x86-64 because, you know, that's such powerful construct that doesn't fit older CPUs, but that's exactly what's slowly happening to JS.
Would we restrict CSS :visited on *.ru domains, because, who knows, is the *.ru registry actually "secure" or "private" by our standards?

If LetsEncrypt wouldn't be the free worldwide provider of "secure context", I'd question the sincerity of this move, the underlying motivation and possible economic incentive.
The only (far-fetching) interpretation I could still draw is about questioning gTLD because one immediate (side or intended) effect of this spec' is to make impossible for developers to use http://mysite.whatever when developing locally
Since *.local is the de-facto only exception offered by implementers it forces developers to follow and no /etc/hosts will save them.
=> Any relation to *.zip, .dev or other .gTLD usage and future browser policies/plans regarding them?

I request storage (and crypto) API to stay out of this ES-for-kid/DRMized-JS specification project.

(Anyone from @tc39 could come here and see what's being done to our programming language?)

[johannhof]

Hi @drzraf, this API defines requirements for browsers to safely allow embedded sites access to cross-site information. In the vast majority of cases this cross-site information contains user identifiers or session data that could be abused by an attacker on an insecure network. Therefore it is restricted to a secure context. What constitutes a secure context and how to improve developer ergonomics should be (politely) discussed at https://github.com/w3c/webappsec-secure-contexts or in individual bugs filed with browser engines.

Thanks!