12 ms·

Chrome 56 Beta: “Not Secure” Warning, Web Bluetooth, and CSS Position: Sticky

110 points by iddan 10y ago

no_protocol 10y ago
So if I just redirect all http requests to https, what unexpected consequences might I run into? 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.
- hughes 10y ago
  If you load any external scripts that are not secure, they might no longer work. Chrome blocks such scripts by default[1]. 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]. [1] https://support.google.com/chrome/answer/1342714 https://support.google.com/chrome/answer/1342714 [2] http://stackoverflow.com/q/21956663/796554 http://stackoverflow.com/q/21956663/796554
- regecks 10y ago
  If you have absolute URLs (http://..../foo.jpg http://..../foo.jpg) saved in documents or a database or something like that, you would need to rewrite them to be protocol-relative or just https:// https:// .
  - ReverseCold 10y ago
    Hmm, but they said SSL is already enabled if you visit the site with https. Shouldn't redirecting http > https be completely risk free then or am I missing something?
    - CharlesW 10y ago
      I think the reply was suggesting that "not advertising or defaulting to [HTTPS]" implies that a quick check for absolute HTTP URLs would be Good Thing.
      - colemickens 10y ago
        Basically every single reply to the GP is making the same point about http assets loaded from a page loaded over https... Surely the GP wouldn't have asked the question they did if their https site was already broken...
    - chipperyman573 10y ago
      If you visit a secure site (https), embedding insecure items (http) will fail because they could do just as much damage as loading the entire page over http.
      - Buge 10y ago
        It depends on what the insecure item is. If it's just an image, it won't fail, it will just grey out the https and not display a lock icon. https://mixed.badssl.com/ https://mixed.badssl.com/
        nailer 10y ago
        That's current behavior, but I wouldn't guarantee it will remain that way, an http image compromises the integrity of the site: it could be manipulated to change the meaning. Imagine reading a news site using an unencrypted CDN and whoever runs the WiFi (or the country you're in) is replacing the images with similar yet different ones, giving a different impression that what the creator intended. 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.
    - rogerdpack 10y ago
      Appears it should be OK unless some inline embedded images are hard coded to "http://" http://" in which case the browser will, I believe, refuse to even try and load them, so you may need to fix that. If they're all relative you're good to go :)
  - discreditable 10y ago
    In the future, the upgrade-insecure-requests CSP directive[1] might help with this problem. I'm not sure what browsers have implemented it yet though. 1. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...
- nkozyra 10y ago
  Well, there is still overhead for using HTTPS, particularly for the handshake. This is unlikely to be palpable at your size, though.
  - Klathmon 10y ago
    The overhead is negligible with the prefetching browsers do, and even that is closing fast with things like TCP fast-open. 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.
    - nkozyra 10y ago
      Oh I agree it's no excuse, OP just asked what the tradeoff/cost was. There is still some but as you say it's negligible and especially so for a very small site like that.
- davidgerard 10y ago
  IME, mixed-content warnings. Tracking down those can be a nuisance. If users can add inline images, you'll basically not be able to avoid these. 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.)
- mpclark 10y ago
  Just did this this week. The only unexpected effect I found was that all our Facebook likes were reset to zero. FB must consider the two versions of each page as being separate and different.
  - askvictor 10y ago
    What type of redirect did you implement? Just curious; this sounds somewhat like the cname vs redirect argument for www. to bare domain name.
    - mpclark 10y ago
      It's a Nginx directive that rewrites requests from http to https with a 301
- byuu 10y ago
  You mentioned community. If you have a forum or message board where people can select their own avatars or post image links, then you'll enjoy the land of mixed content warnings. 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.
  - londons_explore 10y ago
    Run a reverse proxy to host all the user content on your own domain under https instead. Eg. https://yourdomain.com/usercontent/worldofcats.com/foobar.jpg 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.
    - robryk 10y ago
      Don't do this on your domain. Have a separate domain for user content (and, if the content isn't public, better have many separate domains and distribute the content between them; maybe even have a per-user domain). Browsers can be convinced that a particular resource is an html page even if the content-type is wrong.
notadoc 10y ago
While this is obviously useful for anything with a login, there are many content and consumption sites that simply don't need HTTPS.
- tdkl 10y ago
  Yeah, can't wait till my CV and project descriptions (not hosted there) static Jekyll site is somehow insecure and dangerous. [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.
  - charleslmunger 10y ago
    If you're serving them over plaintext http, then they're already insecure. How dangerous that is might be debatable, but there's no doubt that it's insecure.
  - gruez 10y ago
    gitlab pages has https support built in
    - nothrabannosir 10y ago
      For custom domains? I doubt it. Op is not talking about https://<username>.github.io https://<username>.github.io.
      - ben0x539 10y ago
        Comment you're responding to said gitlab, not github. Maybe those code hosting sites need to become more creative in their naming...
        nothrabannosir 10y ago
        The comment I was responding to was talking about gitlab having SSL on their <username>.gitlab.io pages. While correct, that is besides the point OP was making. Which was about custom domains. Gitlab doesn't offer that, either.
kuschku 10y ago
So, how do I manage a website where I allow users to embed arbitrary URLs as image, so I don’t even know which protocol they’ll use, but where I want HTTPS for the page itself? 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.
- hughes 10y ago
  You can try adding `upgrade-insecure-requests`[1] to your page [1] https://developers.google.com/web/fundamentals/security/prevent-mixed-content/fixing-mixed-content https://developers.google.com/web/fundamentals/security/prev...
- tantalor 10y ago
  Who cares about warnings? Do your users browse with devtools open? At worst the users see the grey "i" in circle icon: https://googlesamples.github.io/web-fundamentals/fundamentals/security/prevent-mixed-content/passive-mixed-content.html https://googlesamples.github.io/web-fundamentals/fundamental...
  - bjacobel 10y ago
    A single HTTP request in an otherwise HTTPS page can compromise the privacy and integrity of a user's connection. SSL/TLS isn't just about checking all the boxes so Chrome will give you the prettier icon, there are real stakes for users.
    - andrewmunsell 10y ago
      To expand on this-- 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.
taf2 10y ago
I'm excited for the Web Bluetooth feature. Also position:sticky is very welcome...
- freshyill 10y ago
  position:sticky first appeared in Chrome Canary in 2012, somewhere around Chrome 30, but then they pulled it because of the issues. 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.
rawnlq 10y ago
Hmm I don't understand bluetooth protocol well. What are some security issues I should be aware of if a rando site ask for bluetooth permissions(assuming this feature is gated) and I accidentally click yes? 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 https://www.youtube.com/watch?v=gXu3G3cg52k&feature=youtu.be
- woodruffw 10y ago
  At a glance, here are some issues: 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. [0]: https://webbluetoothcg.github.io/web-bluetooth/ https://webbluetoothcg.github.io/web-bluetooth/
- robwormald 10y ago
  https://developers.google.com/web/updates/2015/07/interact-with-ble-devices-on-the-web https://developers.google.com/web/updates/2015/07/interact-w... is a good primer on the API, and a links to security explainer: https://medium.com/@jyasskin/the-web-bluetooth-security-model-666b4e7eed2#.kkts54677 https://medium.com/@jyasskin/the-web-bluetooth-security-mode...
- m_eiman 10y ago
  I'm most concerned that this will make it feasible to perform rogue firmware upgrades to vulnerable devices that previously were protected by not being connected to the Internet, turning them into various kinds of surveillance and denial-of-service bots…
- MrQuincle 10y ago
  I have already been playing with this as a manufacturer of BLE power switches. 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.
benjaminjackman 10y ago
So their example use case for `position: sticky` is putting a distracting header onto a space constrained mobile device __where the browsers own address bar has the good sense to disappear__ when scrolling down. Not rise from the page like some pixel craving zombie element. 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!
- tomatsu 10y ago
  position:sticky is really awesome for table headers. Emulating that behavior with JS and CSS is ridiculously complicated.
- steve-howard 10y ago
  I agree absolutely that this is exceedingly annoying. That said, it's popular among the people who control design decisions so it's here to stay, for now. 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?
- nitwit005 10y ago
  But plenty of sites already have floating elements that reposition based on scroll listeners. The sticky property just allows it to be done in a performant way.
- lucaspiller 10y ago
  > distracting header onto a space constrained mobile device 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 http://i.imgur.com/PNOQ4Hk.jpg If anyone from Google is here, please do something about this as it is ridiculous.
Sir_Cmpwn 10y ago
>"Not Secure" Warning Nice! >Web Bluetooth What the fuck? >Position: Sticky Nice!
otto_ortega 10y ago
Web Bluetooth?! Am I the only one who just learned this was a thing? 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
- askvictor 10y ago
  WebUSB and webserial are things too ( not necessarily implemented yet)
  - Ajedi32 10y ago
    Not to mention WebVR, Web Payments, the Presentation API, the Gamepad API, and the Web Speech API.
ramenmeal 10y ago
Curious, will position:sticky work for a thead tag? or a tr? All the workaround for this have their faults.
- iso-8859-1 10y ago
  Probably, since position:fixed works: http://jsfiddle.net/brettadamsga/yeAhU/ http://jsfiddle.net/brettadamsga/yeAhU/
r721 10y ago
FLAC support seems to be merged to M-56 too: https://bugs.chromium.org/p/chromium/issues/detail?id=93887 https://bugs.chromium.org/p/chromium/issues/detail?id=93887
- kinlan 10y ago
  Funnily, I managed to get this prioristed by eng when we realised it was already backed into ChromeOS by someone tweeting me :)
- cpeterso 10y ago
  Mozilla is shipping FLAC support in Firefox 51, which is currently the Firefox Beta channel and will be released to everyone on January 24. https://bugzilla.mozilla.org/show_bug.cgi?id=1195723 https://bugzilla.mozilla.org/show_bug.cgi?id=1195723
- deleted 10y ago
  [deleted]
Sephr 10y ago
This is too soon if Google goes forward with the red exclamation point "insecure" flag before there is a free solution for wildcard certificates. 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).
- catmanjan 10y ago
  >Chrome will mark HTTP pages that collect passwords or credit cards as non-secure 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.
  - deleted 10y ago
    [deleted]
- Tushon 10y ago
  Zendesk, for example, has a Let's Encrypt-based system for all those <account>.zendesk.com pages. While it wouldn't be trivial to set it up, it is free and the information is out there if the admins of those sites want to make it possible.
  - kuschku 10y ago
    Not everyone can get whitelisted from the domain creation limits of LE.
darinf 10y ago
One of the coolest features in this release: """ 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. """
- lukasb 10y ago
  <fist pump>
- modeless 10y ago
  Not only that, but "Showing and hiding the URL bar on mobile no longer resizes the initial containing block or elements sized with viewport units such as vh." Thank God! I thought they were never going to reverse this horrible decision. These two changes should substantially reduce scroll jumping on Android which is one of my biggest annoyances on the web these days.
sengork 10y ago
I wish they implemented text reflow on mobile devices, it'd make the web so much more readable for end-users and websites which are not mobile optimised.
- anc84 10y ago
  And usually having control over the zoom level and get reflowed text makes a vastly superior reading experience than TEN LINES IN HUGE LETTERS PER SCREEN like many mobile-optimised sites sadly do.
- jmiserez 10y ago
  Agree, especially since early mobile browsers had exactly that feature. Is it patent-encumbered or what is the problem?
johndoe4589 10y ago
EDIT4: 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/ https://gethttpsforfree.com/ work on HostGator with a shared shell access (not administrative), anybody knows?
k4321 10y ago
Opening up a secure HTTPS iframe (for example from another domain) on a non-secure HTTP website labels the entire site as "Not Secure". This will generate an unnecessary warning to the user when the login form or the payment form is really secured by HTTPS. 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.
- detaro 10y ago
  A warning which is completely applicable if someone modifies the HTTP transmitted site and replaces the secure iframe with a phishing version of it. And since the browser can't tell when that happens, it displays the warning always.
  - k4321 10y ago
    You are correct about that. 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".
    - askmike 10y ago
      > 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. 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.
mtgx 10y ago
"Web Bluetooth", as well as the "Physical Web" sound very scary. Who's going to ensure all of these devices that are accessed this way don't get hacked? Google?
outsidetheparty 10y ago
>the Web Bluetooth API [...] enables web developers to connect to bluetooth devices such as printers 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-privacy 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?)
- pageld 10y ago
  I can think of a couple of things at least in the prehospitalmedial field. Bluetooth ekg machines are used to do documentation and needed to have their data sent to the hospital as fast as possible. Also Bluetooth scanners are used to scan drivers licenses and triage tags. 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.
  - outsidetheparty 10y ago
    Those are... pretty darn good examples, actually. Thanks!
- mkonecny 10y ago
  With location based services making use of beacons, you could easily help a customer navigate your store without asking them to install an app - they just need to visit your website. This is exactly what my startup is working on.
baybal2 10y ago
>Chrome no longer allows opening of pop-ups during inputs which represent a touch scroll, such as touchstart and touchmove. 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.
makecheck 10y ago
There’s too much potential for abuse in web technologies; it’s past time for web browsers to clearly divide their capabilities into higher-level buckets that have restrictions. 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.
- Kadin 10y ago
  I agree, and it seemed like Chrome was aiming for something like that model for a while. But then Google seems to have backed away from it. Except on ChromeOS, Chrome apps are supposed to be phased out by 2018. 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.
  - HappyTypist 10y ago
    On iOS, you can just download a content blocker in the App Store and it'll just work in safari.
twism 10y ago
it’s a shame Apple keeps castrating iOS safari by not adopting open web standards to keep the app store relevant

110 points by iddan 10y ago

So if I just redirect all http requests to https, what unexpected consequences might I run into? 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.

hughes 10y ago
If you load any external scripts that are not secure, they might no longer work. Chrome blocks such scripts by default[1]. 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]. [1] https://support.google.com/chrome/answer/1342714 https://support.google.com/chrome/answer/1342714 [2] http://stackoverflow.com/q/21956663/796554 http://stackoverflow.com/q/21956663/796554
regecks 10y ago
If you have absolute URLs (http://..../foo.jpg http://..../foo.jpg) saved in documents or a database or something like that, you would need to rewrite them to be protocol-relative or just https:// https:// .
- ReverseCold 10y ago
  Hmm, but they said SSL is already enabled if you visit the site with https. Shouldn't redirecting http > https be completely risk free then or am I missing something?
  - CharlesW 10y ago
    I think the reply was suggesting that "not advertising or defaulting to [HTTPS]" implies that a quick check for absolute HTTP URLs would be Good Thing.
    - colemickens 10y ago
      Basically every single reply to the GP is making the same point about http assets loaded from a page loaded over https... Surely the GP wouldn't have asked the question they did if their https site was already broken...
  - chipperyman573 10y ago
    If you visit a secure site (https), embedding insecure items (http) will fail because they could do just as much damage as loading the entire page over http.
    - Buge 10y ago
      It depends on what the insecure item is. If it's just an image, it won't fail, it will just grey out the https and not display a lock icon. https://mixed.badssl.com/ https://mixed.badssl.com/
      - nailer 10y ago
        That's current behavior, but I wouldn't guarantee it will remain that way, an http image compromises the integrity of the site: it could be manipulated to change the meaning. Imagine reading a news site using an unencrypted CDN and whoever runs the WiFi (or the country you're in) is replacing the images with similar yet different ones, giving a different impression that what the creator intended. 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.
  - rogerdpack 10y ago
    Appears it should be OK unless some inline embedded images are hard coded to "http://" http://" in which case the browser will, I believe, refuse to even try and load them, so you may need to fix that. If they're all relative you're good to go :)
- discreditable 10y ago
  In the future, the upgrade-insecure-requests CSP directive[1] might help with this problem. I'm not sure what browsers have implemented it yet though. 1. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...
nkozyra 10y ago
Well, there is still overhead for using HTTPS, particularly for the handshake. This is unlikely to be palpable at your size, though.
- Klathmon 10y ago
  The overhead is negligible with the prefetching browsers do, and even that is closing fast with things like TCP fast-open. 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.
  - nkozyra 10y ago
    Oh I agree it's no excuse, OP just asked what the tradeoff/cost was. There is still some but as you say it's negligible and especially so for a very small site like that.
davidgerard 10y ago
IME, mixed-content warnings. Tracking down those can be a nuisance. If users can add inline images, you'll basically not be able to avoid these. 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.)
mpclark 10y ago
Just did this this week. The only unexpected effect I found was that all our Facebook likes were reset to zero. FB must consider the two versions of each page as being separate and different.
- askvictor 10y ago
  What type of redirect did you implement? Just curious; this sounds somewhat like the cname vs redirect argument for www. to bare domain name.
  - mpclark 10y ago
    It's a Nginx directive that rewrites requests from http to https with a 301
byuu 10y ago
You mentioned community. If you have a forum or message board where people can select their own avatars or post image links, then you'll enjoy the land of mixed content warnings. 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.
- londons_explore 10y ago
  Run a reverse proxy to host all the user content on your own domain under https instead. Eg. https://yourdomain.com/usercontent/worldofcats.com/foobar.jpg 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.
  - robryk 10y ago
    Don't do this on your domain. Have a separate domain for user content (and, if the content isn't public, better have many separate domains and distribute the content between them; maybe even have a per-user domain). Browsers can be convinced that a particular resource is an html page even if the content-type is wrong.

notadoc 10y ago

While this is obviously useful for anything with a login, there are many content and consumption sites that simply don't need HTTPS.

tdkl 10y ago
Yeah, can't wait till my CV and project descriptions (not hosted there) static Jekyll site is somehow insecure and dangerous. [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.
- charleslmunger 10y ago
  If you're serving them over plaintext http, then they're already insecure. How dangerous that is might be debatable, but there's no doubt that it's insecure.
- gruez 10y ago
  gitlab pages has https support built in
  - nothrabannosir 10y ago
    For custom domains? I doubt it. Op is not talking about https://<username>.github.io https://<username>.github.io.
    - ben0x539 10y ago
      Comment you're responding to said gitlab, not github. Maybe those code hosting sites need to become more creative in their naming...
      - nothrabannosir 10y ago
        The comment I was responding to was talking about gitlab having SSL on their <username>.gitlab.io pages. While correct, that is besides the point OP was making. Which was about custom domains. Gitlab doesn't offer that, either.

kuschku 10y ago

So, how do I manage a website where I allow users to embed arbitrary URLs as image, so I don’t even know which protocol they’ll use, but where I want HTTPS for the page itself? 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.

hughes 10y ago
You can try adding `upgrade-insecure-requests`[1] to your page [1] https://developers.google.com/web/fundamentals/security/prevent-mixed-content/fixing-mixed-content https://developers.google.com/web/fundamentals/security/prev...
tantalor 10y ago
Who cares about warnings? Do your users browse with devtools open? At worst the users see the grey "i" in circle icon: https://googlesamples.github.io/web-fundamentals/fundamentals/security/prevent-mixed-content/passive-mixed-content.html https://googlesamples.github.io/web-fundamentals/fundamental...
- bjacobel 10y ago
  A single HTTP request in an otherwise HTTPS page can compromise the privacy and integrity of a user's connection. SSL/TLS isn't just about checking all the boxes so Chrome will give you the prettier icon, there are real stakes for users.
  - andrewmunsell 10y ago
    To expand on this-- 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.

taf2 10y ago

I'm excited for the Web Bluetooth feature. Also position:sticky is very welcome...

freshyill 10y ago
position:sticky first appeared in Chrome Canary in 2012, somewhere around Chrome 30, but then they pulled it because of the issues. 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.

rawnlq 10y ago

Hmm I don't understand bluetooth protocol well. What are some security issues I should be aware of if a rando site ask for bluetooth permissions(assuming this feature is gated) and I accidentally click yes? 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 https://www.youtube.com/watch?v=gXu3G3cg52k&feature=youtu.be

woodruffw 10y ago
At a glance, here are some issues: 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. [0]: https://webbluetoothcg.github.io/web-bluetooth/ https://webbluetoothcg.github.io/web-bluetooth/
robwormald 10y ago
https://developers.google.com/web/updates/2015/07/interact-with-ble-devices-on-the-web https://developers.google.com/web/updates/2015/07/interact-w... is a good primer on the API, and a links to security explainer: https://medium.com/@jyasskin/the-web-bluetooth-security-model-666b4e7eed2#.kkts54677 https://medium.com/@jyasskin/the-web-bluetooth-security-mode...
m_eiman 10y ago
I'm most concerned that this will make it feasible to perform rogue firmware upgrades to vulnerable devices that previously were protected by not being connected to the Internet, turning them into various kinds of surveillance and denial-of-service bots…
MrQuincle 10y ago
I have already been playing with this as a manufacturer of BLE power switches. 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.

benjaminjackman 10y ago

So their example use case for `position: sticky` is putting a distracting header onto a space constrained mobile device __where the browsers own address bar has the good sense to disappear__ when scrolling down. Not rise from the page like some pixel craving zombie element. 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!

tomatsu 10y ago
position:sticky is really awesome for table headers. Emulating that behavior with JS and CSS is ridiculously complicated.
steve-howard 10y ago
I agree absolutely that this is exceedingly annoying. That said, it's popular among the people who control design decisions so it's here to stay, for now. 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?
nitwit005 10y ago
But plenty of sites already have floating elements that reposition based on scroll listeners. The sticky property just allows it to be done in a performant way.
lucaspiller 10y ago
> distracting header onto a space constrained mobile device 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 http://i.imgur.com/PNOQ4Hk.jpg If anyone from Google is here, please do something about this as it is ridiculous.

Sir_Cmpwn 10y ago

>"Not Secure" Warning Nice! >Web Bluetooth What the fuck? >Position: Sticky Nice!

otto_ortega 10y ago

Web Bluetooth?! Am I the only one who just learned this was a thing? 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

askvictor 10y ago
WebUSB and webserial are things too ( not necessarily implemented yet)
- Ajedi32 10y ago
  Not to mention WebVR, Web Payments, the Presentation API, the Gamepad API, and the Web Speech API.

ramenmeal 10y ago

Curious, will position:sticky work for a thead tag? or a tr? All the workaround for this have their faults.

iso-8859-1 10y ago
Probably, since position:fixed works: http://jsfiddle.net/brettadamsga/yeAhU/ http://jsfiddle.net/brettadamsga/yeAhU/

r721 10y ago

FLAC support seems to be merged to M-56 too: https://bugs.chromium.org/p/chromium/issues/detail?id=93887 https://bugs.chromium.org/p/chromium/issues/detail?id=93887

kinlan 10y ago
Funnily, I managed to get this prioristed by eng when we realised it was already backed into ChromeOS by someone tweeting me :)
cpeterso 10y ago
Mozilla is shipping FLAC support in Firefox 51, which is currently the Firefox Beta channel and will be released to everyone on January 24. https://bugzilla.mozilla.org/show_bug.cgi?id=1195723 https://bugzilla.mozilla.org/show_bug.cgi?id=1195723
deleted 10y ago
[deleted]

Sephr 10y ago

This is too soon if Google goes forward with the red exclamation point "insecure" flag before there is a free solution for wildcard certificates. 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).

catmanjan 10y ago
>Chrome will mark HTTP pages that collect passwords or credit cards as non-secure 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.
- deleted 10y ago
  [deleted]
Tushon 10y ago
Zendesk, for example, has a Let's Encrypt-based system for all those <account>.zendesk.com pages. While it wouldn't be trivial to set it up, it is free and the information is out there if the admins of those sites want to make it possible.
- kuschku 10y ago
  Not everyone can get whitelisted from the domain creation limits of LE.

darinf 10y ago

One of the coolest features in this release: """ 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. """

lukasb 10y ago
<fist pump>
modeless 10y ago
Not only that, but "Showing and hiding the URL bar on mobile no longer resizes the initial containing block or elements sized with viewport units such as vh." Thank God! I thought they were never going to reverse this horrible decision. These two changes should substantially reduce scroll jumping on Android which is one of my biggest annoyances on the web these days.

sengork 10y ago

I wish they implemented text reflow on mobile devices, it'd make the web so much more readable for end-users and websites which are not mobile optimised.

anc84 10y ago
And usually having control over the zoom level and get reflowed text makes a vastly superior reading experience than TEN LINES IN HUGE LETTERS PER SCREEN like many mobile-optimised sites sadly do.
jmiserez 10y ago
Agree, especially since early mobile browsers had exactly that feature. Is it patent-encumbered or what is the problem?

johndoe4589 10y ago

EDIT4: 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/ https://gethttpsforfree.com/ work on HostGator with a shared shell access (not administrative), anybody knows?

k4321 10y ago

Opening up a secure HTTPS iframe (for example from another domain) on a non-secure HTTP website labels the entire site as "Not Secure". This will generate an unnecessary warning to the user when the login form or the payment form is really secured by HTTPS. 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.

detaro 10y ago
A warning which is completely applicable if someone modifies the HTTP transmitted site and replaces the secure iframe with a phishing version of it. And since the browser can't tell when that happens, it displays the warning always.
- k4321 10y ago
  You are correct about that. 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".
  - askmike 10y ago
    > 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. 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.

mtgx 10y ago

"Web Bluetooth", as well as the "Physical Web" sound very scary. Who's going to ensure all of these devices that are accessed this way don't get hacked? Google?

outsidetheparty 10y ago

>the Web Bluetooth API [...] enables web developers to connect to bluetooth devices such as printers 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-privacy 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?)

pageld 10y ago
I can think of a couple of things at least in the prehospitalmedial field. Bluetooth ekg machines are used to do documentation and needed to have their data sent to the hospital as fast as possible. Also Bluetooth scanners are used to scan drivers licenses and triage tags. 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.
- outsidetheparty 10y ago
  Those are... pretty darn good examples, actually. Thanks!
mkonecny 10y ago
With location based services making use of beacons, you could easily help a customer navigate your store without asking them to install an app - they just need to visit your website. This is exactly what my startup is working on.

baybal2 10y ago

>Chrome no longer allows opening of pop-ups during inputs which represent a touch scroll, such as touchstart and touchmove. 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.

makecheck 10y ago

There’s too much potential for abuse in web technologies; it’s past time for web browsers to clearly divide their capabilities into higher-level buckets that have restrictions. 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.

Kadin 10y ago
I agree, and it seemed like Chrome was aiming for something like that model for a while. But then Google seems to have backed away from it. Except on ChromeOS, Chrome apps are supposed to be phased out by 2018. 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.
- HappyTypist 10y ago
  On iOS, you can just download a content blocker in the App Store and it'll just work in safari.

twism 10y ago

it’s a shame Apple keeps castrating iOS safari by not adopting open web standards to keep the app store relevant