Blink - Intent to deprecate: Insecure usage of powerful features

https://groups.google.com/a/chromium.org/d/msg/blink-dev/2LXKVWYkOus/gT-ZamfwAKsJ

by robin_reala • 11 years ago

93 95 11 years ago

groups.google.com

Once Let's Ecrypt [0] launches, I suppose most web developers won't have any more excuses not to use HTTPS. It'll be free, pretty easy and quick time wise, plus it'll give you an SEO boost.

Browser vendors are certainly doing the right thing by making http be marked as non-secure, and not implementing unencrypted http/2 and not allowing non-HTTPS access to powerful api are completely reasonable steps to take.

[0] https://letsencrypt.org

psykovsky• 11 years ago

If everybody gets an SEO boost, there is no boost. :)

hucker• 11 years ago

Well, then there's a SEO penalty for not using it...

solaris999• 11 years ago

If you want to be pessimistic about it, anyone who doesn't adopt will get an SEO drop

Aldo_MX• 11 years ago

Except that not everybody will do it since day 1

TazeTSchnitzel4• 11 years ago

What about HTTPS for local testing, though?

thomasfoster965• 11 years ago

Reading through the W3C draft linked to in the announcement, localhost over HTTP will be considered probably secure.

RyanMcGreal• 11 years ago

How will Let's Encrypt be different/better than a StartSSL Free certificate?

organsnyder5• 11 years ago

I used to use StartSSL, but abandoned it for a few reasons:

1. Their user interface is slow and clunky. Acquiring/renewing certificates is a PITA.

2. For organizations, they require both extended personal validation and organizational validation. In addition to being fairly expensive ($100 annually, each), they require you to send images of a bunch of sensitive personal documents (passport, credit card, etc.). While you can often slip by and get certs without them realizing you're getting them for an organization, once they've noticed and flagged your account, each cert requires manual review.

3. Their website hasn't been updated in a number of years. They do not give the impression of being a healthy company.

icebraining7• 11 years ago

Free certificate revocations. StartSSL was crucified for charging $25 for revocations, and not waiving the fee during Heartbleed.

thomasfoster965• 11 years ago

By the looks of the Github account, Let's Encrypt will let me programmatically get a certificate for free when I run non start in my node app, or easily set up HTTPS on my Apache web server, among other things. All for free with minimal work.

tlarkworthy• 11 years ago

Its two commands for free static https hosting on Firebase

https://www.firebase.com/docs/hosting/command-line-tool.html

protomyth3• 11 years ago

What is the value proposition of a certificate from an automated provider? What is the verification? If someone wants to get a certificate for a domain that has ebay or paypal as part of the domain then spoofs those sites, will the automated provide flag this or are the users going to see the nice lock in their address bar? Why bother and not just allow all self signed certificates?

goodnights• 11 years ago

https://letsencrypt.org/howitworks/technology/

r1ch• 11 years ago

Until ad networks make a serious effort to enable https on their networks and CDNs, I can't run https on any of my sites. Mixed content security means no http ads and thus no revenue.

jbb555• 11 years ago

Basically they are destroying the simplicity of the internet in order to push their own agenda. I'd get annoyed about it, but it's not going to be long before it all collapses under it's own weight and something new and lightweight turns up to take over from what http used to be good for.

fpgeek2• 11 years ago

Did you even look at the kinds of attacks that motivate these restrictions before concluding that there was a nefarious agenda at work?

I took a look at a Fullscreen API attack ( http://feross.org/html5-fullscreen-api-attack/ ) and found it pretty creepy even though I knew exactly what to expect and what to look for. Tighter controls over that sort of thing seem like a great idea to me.

ldng9• 11 years ago

Maybe I'm dense but I don't see how requiring HTTPS would solve phishing attacks. To me it falls in the social engineering realm, people clicking link in their mail thay really should not. Having an extra 's' in the URL will not change that. Am I missing the point ?

philh• 11 years ago

But that attack works just as well if feross.org uses SSL, doesn't it? I'm not sure what MITM+fullscreen gets an attacker that they don't get from either by itself.

Which isn't to say there's no reason to only allow fullscreen over SSL, but I can't offhand think of one.

userbinator3• 11 years ago

Memories of receiving tons of full-screen popup and popunder ads (and without any close buttons, address bars, or any other browser controls... thankfully I knew what Alt+F4 did at the time!) may have biased me a bit... but I think the fullscreen API is a bad idea in general - the browser should not allow scripts to do things that modify the UI outside of the content area of the page. If the user wants to resize the content area, he/she should do that through the facilities the OS window manager already provides.

Besides, a similar attack could be carried out even without the fullscreen API - just replace the page contents when the link is clicked, and the same people who don't notice the changes in UI will probably not notice the address bar either (it also doesn't help that browsers are attempting to deemphasise/hide the URL...)

If they wanted "tighter controls", they should just remove the fullscreen API. I guess a lot of web developers won't like it, but the user has always had the ability to fullscreen the browser if he/she wanted to.

icebraining7• 11 years ago

I don't understand your criticism. They are requiring HTTPS to use complex/advanced features. You're still free to serve your handwritten HTML 4.0 over unencrypted HTTP 1.1.

What simplicity is being destroyed here? If anything, they're making it more costly to make complex websites.

cotillion• 11 years ago

I guess he's one of those who can decode both transfer-encoding and content-encoding in real time while watching tcpdump output.

For the rest of us who need tools to watch HTTP 1.1 this changes nothing.

anon4• 11 years ago

One thing I'll definitely miss is being able to look at traffic with wireshark. I've used it to great effect when I had to debug a failing service and wanted to see exactly what the browser was sending that was tripping it.

colinramsay• 11 years ago

"Agenda"? What, the nefarious agenda of making things more secure for everyone?

userbinator3• 11 years ago

While in this case it could be going a little too far since I see how some of these APIs could be used to gather quite sensitive information, it might be a sort of knee-jerk reaction against the trend of "it's for your security" restrictionism that is becoming very common today; and it's a reaction that I think is long overdue... "more secure for everyone" is the same reason often used to justify mass surveillance.

hayksaakian• 11 years ago

I wonder how many "internet of things" things will stop working due to these changes.

sleepychu• 11 years ago

Aren't IOT typically servers not clients? I can't imagine their pages require access to powerful APIs.

revelation2• 11 years ago

The word has been mangled to the point of no recognition, but for low power applications you would want the IOT device to be a client pushing when changes occur.

jpgvm• 11 years ago

Though only tangentially related I do wish EME had been properly shot in the head.

It's just another Flash that hides behind being "html5" (as if they makes it all ok). At the end of the day it's proprietary code executing on my machine that I have little or no control over. It's not just a security risk, it's also a stability concern and generally a terrible idea.

Copyright enforcement should be left to law, content companies shouldn't be trying their hand at it. Who knows, maybe if their content didn't come wrapped in utter crap people might actually part with money for it.

eeZi• 11 years ago

At least it's properly sandboxed.

vertex-four• 11 years ago

Copyright enforcement should be left to law

You would prefer that all copyright violation is a criminal matter rather than a civil one?

organsnyder5• 11 years ago

"Law" isn't limited to criminal cases. Nothing in the poster's statement precluded a lawsuit from being an enforcement mechanism.

kevincennis• 11 years ago

I view EME as sort of a necessary evil.

There was never any chance that large content companies were going to be okay with serving unencrypted media over HTTP. So the choices were:

1. No major film or television content on the web

2. The survival of Flash/Silverlight

3. EME

I'm not crazy about any of those choices, but #3 seems the most reasonable.

M2Ys4U• 11 years ago

4. They should get over it.

lambda• 11 years ago

Between these options, 1 seems the most reasonable to me. I refuse to play along with anyone who thinks that they need to hijack my computer in order to sell me content. They want my money, they can sell me DRM free content.

aikah• 11 years ago

I believe the W3C is an open standard consortium. What Big Entertainment wants to do is none of its concern.Let them use a plugin,there is already an interface for that. EME isn't different from a plugin, that's what you don't understand.I does less sure,but it still relies on something people will have to install on their computer, or even worse, encryption at the hardware level.

revelation2• 11 years ago

Bizarre. HTTPS isn't a guarantee that a site is not malicious. Its not like I could go to a CA and ask them who they signed that cert for and take on any kind of legal responsiveness. Such is the state of the CA system that they will give a cert to anyone with access to a domains MX and some bitcoins.

Instead of this, maybe require there's a user mouse event on the call stack for things like fullscreen.

air• 11 years ago

The intent is to prevent man in the middle -attackers from getting access to those features.

arcatek• 11 years ago

Why would they need the fullscreen access? I could see the interest for cookies or local storage, but fullscreen?

Danilka• 11 years ago

What is going to be the protocol for development environment? Should one deal with ssl just to quickly test out the code?

What if a service streams video, which requires full screen feature? It takes quite a bit more compute power to pack it into encrypted connection, and what if the video is not of any value as a secure content. Why should people be forced to encrypt and decrypt spending extra power (battery, in case of portable devices) on it?

SSL does not guarantee the security de-facto. Also, there is plenty of personal data that is being passed through a non-encrypted connection, which is way more valuable. If this is an attempt to increase amount of secure connections, it is a very inconvenient one. Why not keep giving bonus point for using it (like SEO higher ranking) rather than making pure HTTP not usable.

icebraining7• 11 years ago

Because otherwise a MITM can abuse the fullscreen feature. SSL is a way of ensuring content integrity, not just privacy.

I do think we should have a way of signing content without mandating encryption for these use cases, but until we do, HTTPS is the only choice.

userbinator3• 11 years ago

I do think we should have a way of signing content without mandating encryption for these use cases

SSL has it, it's just usually disabled by default - null encryption with non-null MAC.

pornel• 11 years ago

DevTools can whitelist dev domains: https://w3c.github.io/webappsec/specs/powerfulfeatures/#deve...

What if a service streams video; […] spending extra power (battery, in case of portable devices)

Then they'll encrypt, because it's cheap. YouTube could do it. Only Netflix is making a fuss because they want to legitimize their DRM as a security layer.

It's not 1995 any more. Today even low-end cell phones are orders of magnitude faster than CPUs were when SSL was slow. We've got fast ciphers and hardware-accelerated decoding.

https://istlsfastyet.com/

SSL does not guarantee the security de-facto.

The problem is that HTTP is de-facto guaranteeing insecurity.

• HTTPS is the new HTTP.

• HTTPS+HSTS+preloaded pinning is the new HTTPS.

bd2• 11 years ago

Uhm, I strongly disagree with making fullscreen https only feature.

For WebGL and WebVR community this would be a big step backwards, making browser applications again second class citizen vs native apps.

And it's not like there aren't already strong enough protections in place. Try for example visiting this mock attack site:

http://feross.org/html5-fullscreen-api-attack/

In every browser I tried it was already obviously fake. It doesn't work already with current security tech:

1) browsers ask for fullscreen permission (with big unmissable dialogs)

2) emulated fake layout is very different from real layout (missing all per-user specific browser settings, e.g. bookmarks or extension buttons or any theme customizations, also font rendering looks different)

3) emulated fake browser UI doesn't respond to interactions in the same way as native UI

shangxiao• 11 years ago

The point of that article was that people don't notice subtle changes, especially when their not tech savvy/tired after a long day of work/whatever. Also someone pointed out in the comments that some people tend to ignore changes and click on whatever to get to their destination.

JustGotHere2• 11 years ago

And article is ignoring that the site can then add https and do that fullscreen attack anyway.

A better solution would be to keep showing a message telling you it has gone fullscreen like browsers currently do.

bd2• 11 years ago

Yes, that's true. But for people who don't notice changes there isn't much help anyways.

Even much more primitive phishing will still work on them (just think about those "you have virus / clean your computer" ads from past, with images looking like Windows pop-ups, or remember how those "Nigerian prince" scams intentionally use broken English to selectively address more gullible folks).

These new proposed security measures will not help those people much, they can still be phished from within browser tab content rectangle.

Instead these changes will just basically kill whole class of web applications for a benefit of small subset of population phishable enough with fullscreen attacks but immune to content rectangle attacks.

-----

BTW recent Lenovo Superfish fiasco has shown us that in fact you can't even trust native browser security UI elements. Those real UI green locks on https pages can be as misleading as those JS/HTML generated ones.

I would much more prefer browsers to secure me from known rogue certificates attacks than from hypothetical hard-to-pull-off fullscreen phishing attacks.

TeMPOraL• 11 years ago

And that's one of the reasons webapps will be always second-class citizens vs. native apps - because browsers have to limit tons of useful features to keep users protected from various attacks.

pjmlp• 11 years ago

For WebGL and WebVR community this would be a big step backwards, making browser applications again second class citizen vs native apps.

They still are. Most of the time someone posts a WebGL demo here, they fail to run on my devices that have no issue with OpenGL ES 3.0 for native applications.

TazeTSchnitzel4• 11 years ago

Well, fullscreen wouldn't have to be HTTPS-only, just the permission wouldn't persist for HTTP.

matthewmacleod• 11 years ago

For WebGL and WebVR community this would be a big step backwards, making browser applications again second class citizen vs native apps.

I don't really understand why this is the case — surely they'd just serve them over HTTPS and be done with it?

quinndupont2• 11 years ago

This would work, but I think the issue is that there's an unacknowledged reversal of thinking going on here: HTTPS is the "norm", and HTTP is the aberrant case. The commenter doesn't seem to agree with this reversal, or hasn't realized that it is occurring.

elros• 11 years ago

I guess that's why it's just a proof of concept. Also, those three points you raise would certainly deter you and me from being caught, but e.g. my father (in his early 50s), who uses Word, Internet Banking, Email, pretty much the same way for 20 years and does not understand, for example, the concept of a "folder", he would assume the computer is displaying normal behaviour, because he doesn't have the knowledge to assume otherwise.

"Fake UI" or "user-specific browser settings", "font rendering", are things that don't even (make sense/matter/seem odd) to him.

Ironically, my great-aunt, who's almost 90 but was always somewhat of a "techie", would notice something weird and call me or her son.

But I guess my point still stands.

unreal372• 11 years ago

I didn't get that impression from the mailing list post. They were exploring ways of adding more security depending on context. That's a long way from "https only feature". Perhaps the user just needs to acknowledge the switch (instead of just being notified of it)? Or set a browser flag to override?

silon3• 11 years ago

Is http://localhost / 127.0.0.1 considered secure?

thomasfoster965• 11 years ago

From what I can gather, yes to the former, probably to the latter.

Blink - Intent to deprecate: Insecure usage of powerful features

Related Stories