Intent to deprecate: Insecure usage of powerful features

My concerns over the policy would indeed rapidly diminish as the costs of deploying HTTPS (monetary and mental) approach zero.

Will this also affect flash/unity full screen? Or only HTML5 full screen?

I am not happy with this, unlocking browser features with SSL. First make SSL free and easy to setup.

Also we assume, using HTTPS - the website is legit. What if I use cloudflare DNS or github to host my malicious site, as shown in the examples above.

Given that premise, however, HTTPS doesn't solve the problem, it just
shunts it off to a party other than the browser vendor. In a
HTTPS-only world for html5 games, most developers will be forced to
rely on third parties to provide their encryption - CDNs like
cloudflare/cloudfront, hosting services like github or newgrounds,
etc. In that scenario there's no actual guarantee that the author is
who they say they are, or that the content has been vetted to ensure
it's not malicious, etc. All you've done is slightly raise the cost of
entry for malware while simultaneously erecting huge barriers between
independent developers and their users. We have numerous examples from
app stores like the iOS/Android markets, content hosting sites like
Newgrounds/Kongregate, where malicious parties steal a developer's
app, repackage it (sometimes with additional ads or malware), and put
it back up on hosting sites. HTTPS will do nothing to prevent this
either - to an end user this repackaged content will appear
'legitimate' so if it is considered reasonable to *remove*
prompting/security restrictions on Fullscreen (for example) just
because the content is SSL signed I think that is a huge step
backward.

I particularly object to creating more barriers for independent
developers. The past year has demonstrated that vulnerable minorities
authoring games & multimedia content - not to mention using the
internet in general - are active targets for harassment and violence
that is perpetuated using internet technologies to get personal
information: Required personal information on whois (thankfully
registrars are willing to mask information now), social engineering
against service providers, etc. My understanding is that there is no
way to acquire a valid SSL certificate without providing personal
identity information, since browser vendors helpfully destroyed the
ability to use self-signed certificates. This creates another point of
vulnerability for people authoring HTML5 multimedia content because
another random party has access to their personal information and is
likely to disclose it to hostile parties. I have the necessary time &
resources to acquire a SSL certificate, and have done so in the past,
but I know from those experiences that this is not something it is
reasonable to expect of all people who want to author HTML5 content.
In particular I'm not even sure how someone from a third-world or
restrictive country would go about legally acquiring a valid SSL
certificate. Is it easy for them to do that, or are there plans to
address that? If these security mechanisms disproportionately harm
people outside of the privileged west I think that would be highly
regrettable.

-kg

+1 for Klaus
This would be a very very bad idea for all panoramic and online vr producers. Also for their clients and users.
I guess it is google 'april fools'...

Tuur

Seems reasonable, though I think dos and amplification (100x
demonstrated in the past) through ssl is ignored in the TLS speed
concerns.

In the long term and depending on the depth of features that are
moved to requiring https then it may make it more difficult to keep
serving http despite https servers being saturated.

Fullscreen, pointer lock, and keyboard lock have spoofing risks that multiply, the more of them you have enabled. It may make sense and be feasible to restrict combinations before restricting the individual features.

Jeffrey

As a core developer on Modernizr I'm wondering how feature detection will be effected by these changes? If I do a check for the fullscreen api on a http site will it return false? Would it inform me through throwing an exception that this feature is available but requires https?

This is speculation at this point, but I expect that
Document.fullscreenEnabled would return false in this situation, so
that it could be detected synchronously and without actually trying to
enter fullscreen.

It would be quite bad if any APIs which get restricted to secure
origins will only fail after trying to use the API and in a way which
is indistinguishable to some pre-existing failure, so that's
definitely something to keep in mind.

Philip

Why exactly? It's not like there's an alternative other than moving to TLS.


--
https://annevankesteren.nl/

I imagine that there are libraries that would want to work on both
secure an insecure origins in the presumably long and somewhat bumpy
transition period. If the thing that requires a secure origin is just
a nice-to-have, like say fullscreen mode or "take picture and insert"
for a rich text editor, it's nice to be able to hide that bit of UI if
you know that it isn't going to work.

It's a safe bet that many Web developers will be unhappy with any of
the suggested changes, and making the behavior impossible to feature
detect would make it more difficult for them.

(Just guessing, I'm not an actual Web developer.)

Philip

I grouped that poorly. By 'a nice-to-have, like say fullscreen mode or
"take picture and insert"
for a rich text editor' I meant both features in the context of a rich
text editor, where removing those features from the UI would still
leave you with something worth using.

But on second thought, when the feature isn't a nice-to-have but the
central purpose, it's equally helpful to know up-front that it's not
going to work, at least for a library that could end up used in any
context. It's a solved problem for Fullscreen
(document.fullscreenEnabled) but I haven't looked at the other
features.
Point taken, my remark could be seen as gleeful ignorance rather than
an honest admittance that I could be wrong.

Philip

Given that fullscreen (just to pick one example) is out in the wild, I
think there will be significant UX issues if fullscreen API calls
suddenly start failing without any obvious reason. Most websites will
probably never be updated to communicate to the user that the problem
is the page being accessed from a non-secure origin.

In some cases the solution will be for the user to replace 'http:'
with 'https:' but they don't have any easy way to know that. Some
websites don't have a secure version in which case the developer will
need to update the site, but if the feedback is poor there will be
little reason for a typical user to realize that they need to complain
to the developer, and the developer might not realize that they need
to update their website to conform to these new standards. The fact
that these changes probably won't be rolled out with equal timing in
different browsers could easily lead to end users assuming the browser
they're using is broken.

I think changes to existing shipped APIs in wide use like fullscreen
need a lot of careful thought applied in that area if you don't want
to have a painful years-long evangelism just to get existing apps and
samples and tutorials working again. Even once that evangelism work is
done, outdated information out there will probably continue to mislead
newbie developers.

So given this, I want to echo Philip's statement here: It needs to be
possible to detect that these features are unavailable in a given
context, and perhaps possible to get a clear explanation of why that
you can present to the end-user or respond to (for example by
redirecting to https.)

slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#service-worker-postmessage
you get a promise rejected with a DOMException whose name is
"SecurityError".

I think Philip's point about existing APIs requiring some kind of
feature detection to ease transition makes sense though. On the other
hand, if the numbers for these APIs are low anyway, as has been
suggested for some (e.g. geolocation), it might be more effort than
it's worth.


--
https://annevankesteren.nl/

Yeah, perhaps something like Permissions.available() so you can
feature detect whether or not to include certain UI. On the other
hand, if the end game is going to be TLS, libraries should simply tell
their embedders that. It's not entirely clear to me that making it
easier to write non-TLS application UI is a worthwhile investment.


--
https://annevankesteren.nl/

I'm sorry for not adding my voice to this discussion when it was
active, but I am also unhappy with the direction to make these
features HTTPS only. I've never seen a credible phishing attack from
full-screen content, and think that the visible warnings that already
show up for that feature as well as getUserMedia and geolocation are
sufficient to guard against attacks. There is a long tail of smaller
sites that use features like WebGL, WebVR, and camera input to deliver
really cool experiences, and it's infeasible for the site authors to
obtain SSL certificates. I am not an owner of one of these APIs but
believe that this effort is misguided and will drive users away from
browsers based on Blink.

-Ken

Specific to full-screen, wouldn't disabling the pinning be enough? That way, existing http based full screen would still work, but the user would have to authorize it every time, making sure it isn't abused without the user understanding that the current site is going full screen.

Geolocation and getUserMedia I can see it makes sense for.

Encrypted Media Extensions, the inclusion isn't for the user, or the hoster (as they would be the decider whether to use https) so I assume its for 3rd party media providers to trust the technology?

Device motion / orientation pretty esoteric; straight MitM script injection gives you any on page attack vectors; forcing https doesn't prevent bad actors for off page though I suppose it ties blame?

Fullscreen however seems unnecessary to include in this group:
You display bankofamerica.com (not-secure)
You don't allow grants to persist in HTTP
Which is a noble goal, however this is far more aggressive and moving towards trying to make http undesirable everywhere

For users of these features to keep their pages working; they then have to keep their certificates always up to date, rather than just leaving a page up. Which includes being aware of entire CAs and every certificate they have ever issued being dropped (e.g. CNNIC), protocols and certificates that use them being deprecated (e.g. SHA-1-based signatures, non forward secrecy, and obsolete cipher suites). People are bad enough keeping old pages html up to date; hence the horrible garbling and twisting of the UA string; or the pain around css prefixes causing browser vendors to have to start accepting other browsers prefixes.

I understand there is a general desire for everything everywhere to be https and there are a lot of bad actors; whether government scale; isp (comcast injecting ads http://arstechnica.com/tech-policy/2014/09/08/why-comcasts-javascript-ad-injections-threaten-security-net-neutrality/) etc

But there is also a risk of weakening the trust in https. Outside the security community; custom domains are probably seen as far more important than https and even outweigh sites being broken to some people due to MitM injection or manipulation. While a lot of providers for cloud services allow https and/or allow custom domains; many either don't do both, or use the requirement as the marker higher costs.

Where do you see this going? For example say in the future every cloud provider accepts tls for custom domains (we aren't there yet), and I have a custom experiment on Google App engine, another on Heroku; a repo and some pages on Github, something on Azure and something else on Amazon; a merchandise shop on cafepress; a product line on shopify and "end of line" shop on ebay; a blog on wordpress; maybe also using a couple cdns; some legacy some current - all on custom domains. Do you generate a cert for all of them? Or are you passed the tipping point and don't want to renew and keep up to date that many certs? Just make a wildcard (which your CA hands over the keys to in a plain text email)? A start up in SF is doing something exciting, so you hand over your wildcard and keys to test it out...

Also you get unintended side effects from forcing the issue like gogo which doesn't want video streaming over its airplane wifi; but since a lot of traffic is now https it MitM all https to do packet inspection and prevent it http://www.tripwire.com/state-of-security/latest-security-news/heads-up-frequent-fliers-gogo-inflight-wifi-found-issuing-fake-ssl-certificates/

I'm all up for SSL everywhere; but lets see how things like https://letsencrypt.org/ work out first and how auto renewal fits into this picture; if other providers step up to offer similar services and what cross platform features are like.

Though looking at responses you could probably just take Fullscreen out of the set of features and most of the complaints would go away ;-)

And also hopefully pointer lock isn't in the group...