Chrome 56 Beta: “Not Secure” Warning, Web Bluetooth, and CSS Position: Sticky
blog.chromium.org
blog.chromium.org
And let's keep in mind in the real world, it's going to be at least 3 times bigger than that because it's not a sticky bar for ants after all. And it'll be rocking its best friend Mr Hamburger Menu, some social-tracking-sharing-buttons, and a banner ad for whatever was mis-classified from the background of the weighted average of the last 10 Facebook pictures you appeared in.
Just the text please! Viva le reader mode!
This is my pet hate with Google's AMP mode which most sites seem to be switching to.
On my iPhone 5S it breaks hiding the browser's address bar when you scroll, then you have the AMP 'address bar' of the same size, then you finally get to the site's sticky header and footer. On Huffington Post the content is around 50% the size of my screen. Oh and it breaks Safari's Reader mode, which I assume also means accessibility features.
http://i.imgur.com/PNOQ4Hk.jpg
If anyone from Google is here, please do something about this as it is ridiculous.
And in case if someone from Google is listening, give the option to opt out of this AMP crap, I'll gladly pay for extra bandwidth.
While I understand the pain of (sometimes) having broken sites when AMP is on, this really helps when someone is on a country where mobile internet is expensive.
How exactly do you land on AMP pages? Can't you just use Firefox on you phone?
I believe this is actually due to Safari iframe bugs. See: https://medium.com/@dvoytenko/amp-ios-scrolling-and-position...
But that'd be crazy, right?
Since when?
On a regular desktop you would not have this problem: you can have a menu far away from the content. You can have tool bars. You have the name of the tab and the URL giving you context, and the page need less context switching because you can just display more instead of requiring to juggle with what the viewport can display. But on the mobile, context switching is very hard to do right, and must be accessible from your thumb.
It would also reduce the number of old articles submitted to HN as a nice side-effect.
Works already in Safari, but alas only in Chrome Beta.
It is a lot simpler and more robust than the Javascript approaches I found.
Note that what you want is different from what the user wants. I am not alone in thinking that stickies never add value, no matter how convenient the designer thinks they are: https://alisdair.mcdiarmid.org/kill-sticky-headers .
(It's always refreshing how civil disagreements on HN can be. Thank you for your thoughtful reply!)
So do we use a javascript solution that also performs like crap, or accept that this is a common use case and provide a standard way to do it?
Please install an ad blocker. uBlock Origin works wonderfully in Firefox for Android.
""" When content changes above the viewport, Chrome now automatically adjusts the scroll position to keep content in the viewport fixed unless the CSS overflow-anchor property is set. """
Not-for-profit hobby site/community with a couple hundred regular users. Have been running https with Let's Encrypt certs for a year but not advertising or defaulting to it. No legacy systems or other entanglements.
There is a forum that allows users to post inline images and media from other domains.
Depending on your server setup, if you run multiple web domains from the same server then web clients that do not support SNI may fail[2].
You could do this quite subtly as a way to influence people by making certain figures appear more sinister.
These warnings tend to get tougher over time, so what's grey now may be red next year.
Surely the GP wouldn't have asked the question they did if their https site was already broken...
1. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...
Let's Encrypt certs work on pretty much every device. (Some Comodo certs don't work on older Android, for instance - we hit this at work and switched those sites to Let's Encrypt, problem solved.)
Add the header "Content-Security-Policy: upgrade-insecure-requests" and the mixed content errors will go away, but you'll experience a new problem.
About 30% of images/avatars will break, and of those, roughly 10% of them will cause the page loading animation to keep going for 2-3 minutes before finally timing out. I presume this is due to some sort of server misconfiguration on their part, as most non-HTTPS sites fail fast.
Give it a few months and users will slowly update their avatars and stick to sources that support HTTPS (like imgur), but don't expect the problem to ever go away completely.
Eg. https://yourdomain.com/usercontent/worldofcats.com/foobar.jp...
There exist simple php scripts which can do that for you. Beware to sanitize the URL very well, and probably enforce file size rules.
Plus TLS false start and TLS resumption are already here and work great for repeat visits to remove that extra overhead.
Performance isn't an excuse for not using TLS anymore.
Feeling nostalgic for FAX spam? Let's update it for the modern era!
(Kidding. A little bit. The Web Bluetooth spec addresses these concerns at length -- https://webbluetoothcg.github.io/web-bluetooth/#security-and... -- but mostly as a "here are the many, many ways this could be used maliciously", with not nearly enough "and here's how we plan to prevent that" for my taste.
I gotta say this is an attack surface I'd prefer we'd left buried deep underground; I can't think of any device I'd feel safe allowing a website to pair with. Keyboard? Keylogger. Printer? Physical spam. Headphones? Audio spam. Who wants this?)
The less manual input a provider has to do, the better. Then they can spend their time making sure the patient is being taken care of.
Most ems documentation is done on web applications instead of desktop apps so it can work on anything from an iPad to a surface to a tough book.
You don't want to know how these things are hooked up today.
What are free sites that give every user a subdomain for their profile/site/etc supposed to do? There are many open source multi-user site platforms that follow this pattern, and all of these platforms now effectively have a huge monetary subscription fee associated with them due to the fact that you now need to purchase a wildcard certificate in order to not scare away users.
There is no free wildcard SSL certificate service, so Google is essentially forcing you to pay money to not scare users away from your site.
I am all for this change eventually happening, but not until all DV SSL use cases are covered by free services. Until then, this change is inappropriate.
If Google wants to punish sites that can't afford or won't pay for expensive wildcard certificates, then they should offer a solution of their own (like their own ACME CA that supports provisioning wildcard certs).
I'll admit when I first heard of them flagging HTTP password fields, my instinct was to write a little javascript to "mimic" password input field behavior (and store the real password away somewhere else, then at submit time, it sends in the correct data). But if it's just a tiny warning on the url bar, meh, not sure if I care...
Also note that https://letsencrypt.org appears to offer free CA certs.
That is probably what I am going to do for the internal site I maintain at work, since I can't get an SSL certificate for such a thing.
All this change is going to do is make password eavesdropping in person easier.
I guess people could do self signed certs that expire in "100 years" but you're right, even installing those can be super painful, and people may not go that far. Of course, initially what people will do is "nothing" and just let the insecure message appear, since it doesn't actually block any functionality seemingly...
So for that $50, you can double all the specs on your server, or get a little green lock in your URL bar. And don't forget, we're not all in the US. I know a guy in Venezuela that doesn't have $50USD to spend on an SSL certificate.
I understand it costs money to run a CA. But if Let's Encrypt can run one for free, then surely so can Google, if they're so gung-ho on 100% of the web being over HTTPS. If you want that to be a reality too, you need to back free wildcard certificates. Otherwise you'll never be able to deprecate HTTP.
What happened to the hobby / non profit apps, blogs and forums that fill 90% of the web and my bookmarks? All of them have a login form somewhere. Tons of people already use secondary emails or throwaway emails, but these site owners now have to pay for SSL or have to upgrade their shared hosting to "business" or the like to get SSL included, or pay extra fees to install SSL.
If all they do is look for a password field that means pretty much any phpBB or wordpress blog out there is defacto "insecure" and the owners of those sites now need to find a way to get SSL on their (most likely)shared hosting. Mine is not free at all, it requires "installation" fees, plus "dedicated Ip" so in the end it cost near as much as just buying their SSL package.
At this point though it's very unclear how Google will find those "insecure" password fields. Does it honer the no-follow? Because last time I heard it's not useful to get a login form page indexed anyway.
I'm going to get skewered alive for saying this, and I do believe their intentions were noble, but I honestly think Let's Encrypt has done a lot more harm than good.
It's completely deflated the opposition to the CA racket, but not given a comprehensive alternative.
There are servers that can't run certbot for a variety of reasons (including administrator policies that people running the webservers can't control.) The 90-day expiration is the most arduous of any CAs out there by far. Not only are there no wildcards, but there are strict limits on the number of subdomains you can register per week.
And if you don't like it ... too bad. There are zero free alternatives.
Most of us are hackers and can work around these limitations, but not everyone can. You can't expect most people to set up certbot, let alone write their own version. You can't expect them to build some system that automatically batches and registers new subdomains and maintains all those certificates.
> I guess HN is popular with techies who have root access on their servers
That's a lot of it as well. I'd go so far as to say the majority of internet sites out there (by number, not by traffic volume) are little commodity hosting firms that give you a web GUI version of an FTP client, and maybe if you're lucky charge you $10-20 a month for SSL as a checkbox feature in the payment options.
> At this point though it's very unclear how Google will find those "insecure" password fields.
It will probably just look for <input type=password> and if that exists, show the "Not Secure" message.
As to the compute power you can buy for that, it could be that says more about the cheapness of compute power than it does about the expense of SSL certs.
As to Let's encrypt running for free, well the post I was referring to indicated they didn't want to go that route, also you do know they're actively soliciting donations at the moment because, guess what, you can't run a CA for free...
Making the web open only to commercial entities is a huge problem by itself. I definitely would not want to make that a premise or assumption to participate in the Internet as an equal player.
I wasn't willing to accept the Let's Encrypt limitations, and so I paid for a three-year AlphaSSL wildcard certificate for ... I believe $132 or so.
> As to the compute power you can buy for that, it could be that says more about the cheapness of compute power than it does about the expense of SSL certs.
Not really. There is absolutely no reason it should cost $5 to run openssl with a SAN of "www.byuu.org" and $50 to run openssl with a SAN of "*.byuu.org" -- the verification process is 100% identical for both.
That is 100% pure, unadulterated greed. They charge that rate because they can.
> because, guess what, you can't run a CA for free...
I know, the auditing fees are obscenely expensive and required every six months.
Google could afford it if they want the web to be 100% HTTPS. It wouldn't even be a drop in the bucket for them. It'd be a fraction of a sliver of a drop.
Will probably get hated on, but you should shell out for your own domain if you're collecting this info - there are quite a few BYO domain, free hosts.
And even if you do need more:
> If you are a large hosting provider or organization working on a Let’s Encrypt integration, we have a rate limiting form that can be used to request a higher rate limit.
20 users signing up a week - likely with a retention of a few percent - is not a "large hosting provider".
You might have a few hundred users max, and already will be far over the rate limits.
Couldn't you include an ACME request for a new subdomain certificate into the "create account" script?
This would certainly add some complexity (especially with automatically fulfilling the "proof-of-ownership" challanges and properly renewing all the subdomain certificates) but it seems doable with less running cost than a wildcart cert subscription.
Edit: On second thought, this does leak some interesting data to the CA - such as, how many users you have, what their usernames are and how your rate of new signups is.
If you're using Let's Encrypt that'd also limit you to 20 new users per week so I think you'd need a more complicated approach than that (or a different CA). Batching into groups might work but then user provisioning time increases. Wildcard certs do seem like the right way to go here, and the cost is pretty minimal
Let's Encrypt and certbot. It's all but trivial to SSL your site and keep it up to date if you control the system.
Here's how I SSLed my blogs. This was interactive, but fully scripting it would be easy: https://rocknerd.co.uk/2016/12/04/rocknerd-is-now-fully-ssl-... Took me literally minutes to set up, it took more time to track down the http:// images to fix the mixed-content warning.
Lets Encrypt has a limit of 20 domains per week for you.
So you end up with at most a few hundred users.
https://letsencrypt.org/docs/rate-limits/
If that's not enough for your use case, you're probably big enough that a wildcard cert is a negligible expense.
We're talking about edge-cases within edge-cases at this point: a service that (1) offers HTTPS subdomains (2) hasn't been able to get a rate-limit increase from Let's Encrypt (3) is unwilling to buy a wildcard cert (4) either is growing by hundreds of subdomains a day, or has a significant amount of clients who can't wait a few hours for a cert but won't buy their own. That's so oddly specific, I'm not surprised people aren't going out of their way to cater to it.
If I want to build my own little Github sites, I'd already run into the problem.
And, in fact, I've run into the limits several times before, and had to use startssl certs for far longer than planned because of that.
Will I just have to deal with the yellow "mixed content! insecure!" warning? Will I have to proxy requests?
There’s many forums like that in the web.
[1] https://developers.google.com/web/fundamentals/security/prev...
In the long term you'd have to "hope" the whole web transitions to https and just rewrite the url's to https, or cache them locally or proxy serve them locally. HTH.
Something like:
At worst the users see the grey "i" in circle icon: https://googlesamples.github.io/web-fundamentals/fundamental...
Imagine you have a website with a payment form on an HTTPS page, but you embed some external analytics script over HTTP. If your visitor's request is MITMed (e.g. they're in a coffee shop or some other insecure WiFi access point, etc), then an attacker can modify the script (that's over HTTP) to send these credit card details to the attacker's server. Once there's a single HTTP resource on the page, HTTPS means a whole lot less, hence the scary warnings.
More like if there is a single line of 3rd party code.
That's quite concerning as far as warning signs go.
And I don't want to have to compromise the users safety by switching entirely back to HTTP, which would just give no warning.
Will it be able to take over bluetooth speakers or robot toys? They must be in discovery mode for it to connect so I am safe right? Then it will just be privacy issues which I can live with.
Otherwise it looks pretty cool. E.g, controlling a drone from a webpage: https://www.youtube.com/watch?v=gXu3G3cg52k&feature=youtu.be
Every bluetooth device has a unique MAC-like address, which could be used to track you (or your device, at least).
There are also obvious privacy/security issues with the fact that device-stored information (full name, location, biostatistics, etc) can be accessed by any JS loaded onto the same page (read: analytics companies).
The whole Web Bluetooth spec is online[0], if you'd like to read it for yourself.
It does allow for cross-platform BLE access leveraging JavaScript in the browser. The experience of someone gives permanent access is similar to running an app on a phone.
This means you can do a scan request from the browser and all BLE devices respond. Or you can silently listen to advertisements. I don't think you can only give access to particular devices and for example hide the fact that you have a Fitbit or Apple watch.
For smart home applications it is cool for configuration but not for daily use. You don't want anything rely on the user opening up a browser. Apps much more naturally run in the background so the downtime of the browser is a serious hurdle.
Every day I'm shocked by new BLE devices coming in that leak information or are improperly protected. I would only give permissions to sites that you would definitely trust with this.
Something that can come out of this is better attention to multi-device access to BLE devices. Keys that are set up for bonding can not be shared easily with other users. Apple brings its usual Apple-only solution in the form of Homekit, but it would be better to have keys that can be shared across platforms. If the browser becomes also a player this is gonna be important.
Recently I have grow interest in progressive web apps, I wonder if there is a list of the sensors/interfaces that can now be accessed from a web browser, it will certainly be helpful
Wow. I remember, people were complaining that Google were the only major ad network company that did not forbid onthouch* code in ads, and on that has picked a principled stance on allowing them.
Two buckets that come to mind: maybe you should have to specify that either you are developing an “app” or you are developing a “page”. And no page should be able to do things like create sticky-elements (not to mention a zillion other capabilities) because we all know some Obnoxious Clueless Ad Company will take about 13 seconds to start ruining your browsing with it. Anything identified as an “app” should be impossible to load in a normal browser, accessible only under a dedicated home-screen icon with a special sandbox, etc.
Personally, I am really unhappy with the direction of the web right now. Ads have gotten more and more intrusive (particularly on mobile), and it seems like every site is doing some sort of shitty "sign up for our newsletter!" or "but wait there's more!" overlay. Blocking and display-control mechanisms have seemingly fallen behind (again, especially on mobile, where for the typical user there's basically no viable ad blocking solution).
I've heard web developers defend all of this from a business perspective (we need the ad revenue), but it seems really shortsighted. All it's going to do is drive users to walled-garden apps, probably dominated by one or two big players in each market category, and the friction to get your content or product in front of customers will increase tremendously.
Who's going to ensure all of these devices that are accessed this way don't get hacked? Google?
Even if your don't care about secrecy, you should use HTTPS to ensure your content doesn't have ads or malware injected into it by your ISP (which happens) or a WiFi hijacker (which happens). If a user of yours sees an ad or gets a virus from someone injecting it in your website, they are going to blame you.
HTTPS protects the site owner just as much as the site user.
But it's certainly more overhead particularly for mom and pop businesses. I suppose it will drum up a lot of business for web developers though, a Chrome stimulus of sorts.
> Your users can't be easily MITM attacked
[edit] I'll guess I'll have to find a new host then, since Github pages doesn't support https on custom domains. Perhaps Netlify, seems to support Github hooks.
Maybe those code hosting sites need to become more creative in their naming...
If the Chrome development team implements this new security feature they need to check that the window where the form exists is secure by HTTPS or not, and not only check if the top window is secured with HTTPS or not.
I think that the main problem with iframes (and frames in general) is that it's impossible for the user to check in an easy way where they originates from. If the URL bar would automatically change to the iframes URL when the user hovers the iframe it would at least give the user a possibility to check where the iframe originates from and there would be no need to label the entire site as "Not Secure".
Exactly, just like all other resources (assets, media).
> If the URL bar would automatically change to the iframes URL when the user hovers the iframe
Not only is this extremely confusing for anyone who isn't an expert it also breaks when you don't use a mouse. It can also be circumvented really easy by simply hiding an iframe.
-----
Why exactly don't you like the current behaviour? If you load a page over HTTPS that loads a bunch on insecure pages inside iframes, the page _is_ insecure.
A coworker was looking for a JavaScript sticky solution for an internal tool, and since that team could dictate what browsers the users should use, she started building it around position:sticky. Soon enough the property disappeared and she had to go with JS anyway.
The company got bought by their largest competitor a few months ago. I never would have guessed that the company would be gone before this finally got released.
Nice!
>Web Bluetooth
What the fuck?
>Position: Sticky
Nice!
Bah, it's not free on HostGator even with a free certificate:
_Do you authorize the $2 / month or $24 / year dedicated IP charge? (Dedicated IP required for SSL) *_
_Do you authorize the $10.00 SSL Installation fee?_
EDIT3:
Re: having to buy a SSL on a hobby site / forum ...
Ok I see HostGator allows third party SSL it's not super straightforward but at least it seems possible to use a free SSL from Let's Encrypt and then get it installed...
I have shell access too, but it's not "administrative" access so afaik, the Let's Encrypt "Certbot" would not work?
Would https://gethttpsforfree.com/ work on HostGator with a shared shell access (not administrative), anybody knows?