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

https://blog.chromium.org/2016/12/chrome-56-beta-not-secure-warning-web.html

by iddan • 10 years ago

110 149 10 years ago

blog.chromium.org

no_protocol2• 10 years 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.

hughes2• 10 years 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

[2] http://stackoverflow.com/q/21956663/796554

regecks• 10 years ago

If you have absolute URLs (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:// .

ReverseCold• 10 years 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?

discreditable• 10 years 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/Co...

nkozyra2• 10 years ago

Well, there is still overhead for using HTTPS, particularly for the handshake. This is unlikely to be palpable at your size, though.

Klathmon• 10 years 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.

davidgerard2• 10 years 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.)

mpclark2• 10 years 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.

askvictor2• 10 years 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.

byuu6• 10 years 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• 10 years 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.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.

notadoc2• 10 years ago

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

tdkl2• 10 years 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• 10 years 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• 10 years ago

gitlab pages has https support built in

Buge4• 10 years ago

Well China intercepts http traffic and inserts javascript malware joining users into a botnet that DDOSes github pages of human rights organizations. It depends on what you mean by insecure and dangerous.

crooked-v• 10 years ago

"Your users can't be easily MITM attacked when they visit your site" is a pretty big benefit to every site out there.

kps• 10 years ago

  > Your users can't be easily MITM attacked

Ha, ha. Your browser trusts your corporate/institutional/national proxy, or else.

diafygi• 10 years ago

You are forgetting half of the benefit of HTTPS. Not only is content kept secret, but it is also kept unmodified.

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.

notadoc2• 10 years ago

Hmm, good point. The ad injection thing is quite relevant to developing markets, where many ISPs routinely inject ads onto sites.

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.

robwormald2• 10 years ago

the other thing to note is that a lot of new APIs (and older ones which are being updated) require HTTPS - geolocation, webBT, webUSB, service workers, etc, all require HTTPS (or will, soon).

kuschku8• 10 years 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.

hughes2• 10 years ago

You can try adding `upgrade-insecure-requests`[1] to your page

[1] https://developers.google.com/web/fundamentals/security/prev...

tantalor• 10 years 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/fundamental...

bjacobel2• 10 years 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.

kuschku8• 10 years ago

No, they see a yellow warning icon instead of the green https, and in some browsers the https is even red, and strikethrough.

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.

TheCoreh• 10 years ago

You could (and in fact probably should) do what GitHub does. Fetch the images, store a copy and serve them yourself. That way even if the external URLs stop working, the images on your forum/site will remain functional.

no_protocol2• 10 years ago

This is scary to me so I haven't tried it yet. If I'm allowing users to upload arbitrary files, I might have to deal with things like copyright laws. It doesn't sound fun. Does anyone have relevant information for such a site in the United States?

rogerdpack4• 10 years ago

In the short term, as long as you don't have any password/CC prompts, you can continue using HTTP.

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.

MrQuincle3• 10 years ago

Sounds like a perfect CDN opportunity. This doesn't exist yet?

Something like:

https://user.imagecdn.io/website/image

taf2• 10 years ago

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

freshyill• 10 years 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• 10 years 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

woodruffw• 10 years 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/

robwormald2• 10 years ago

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-mode...

m_eiman• 10 years 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…

MrQuincle3• 10 years 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• 10 years 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!

steve-howard• 10 years 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?

nitwit0052• 10 years 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• 10 years 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

If anyone from Google is here, please do something about this as it is ridiculous.

rcheu2• 10 years ago

On my iPhone 5S it breaks hiding the browser's address bar when you scroll

I believe this is actually due to Safari iframe bugs. See: https://medium.com/@dvoytenko/amp-ios-scrolling-and-position...

tdkl2• 10 years ago

Google fix = buy a bigger phone, so you'll see same amount of content then 4 years ago.

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.

kasparsklavins• 10 years ago

Even AMP own page suffers from headers taking up 1/3 of the screen on mobile devices. https://www.ampproject.org/

sametmax• 10 years ago

If you write a mobile SAP, you may need a quick way to change context. Gestures are limited. If at one point you need buttons / links to be always available for the context switch, then a sticky header or/or footer is a logical solution and is what is used in a native apps anyway. It also has the additional benefits of giving you a place to put something helping to identify said context, such as a label, an icon or some shape/color.

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.

agumonkey• 10 years ago

Their css example is badly done but why not.

kinlan2• 10 years ago

I wrote that demo. I was a little behind schedule and needed a quick example that highlighted the point. I'm not disagreeing with you but there are plenty of good usecases for this and in the case of my blog it's easy to lose track of the current section in the article.

MrQuincle3• 10 years ago

It doesn't bother me so much, but one thing about context that I would appreciate is date and author.

It would also reduce the number of old articles submitted to HN as a nice side-effect.

kalleboo• 10 years ago

I agree I hate sites that do that, but changing it to a CSS property instead of some custom half-assed JavaScript is an improvement because now there's at least a hope of being able to block it with some extension.

gardarh• 10 years ago

I think you're forgetting the cookie warning.

coldpie• 10 years ago

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

Please install an ad blocker. uBlock Origin works wonderfully in Firefox for Android.

tomatsu• 10 years ago

position:sticky is really awesome for table headers. Emulating that behavior with JS and CSS is ridiculously complicated.

joakleaf• 10 years ago

I needed "sticky" today for a table header that I want to keep visible as the user scrolls on the page...

Works already in Safari, but alas only in Chrome Beta.

It is a lot simpler and more robust than the Javascript approaches I found.

nitwit0052• 10 years ago

It's also broken for tables in Firefox despite it reporting that it supports the style: https://bugzilla.mozilla.org/show_bug.cgi?id=975644

JadeNB2• 10 years ago

I needed "sticky" today for a table header that I want to keep visible as the user scrolls on the page...

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 .

Sir_Cmpwn• 10 years ago

"Not Secure" Warning

Nice!

Web Bluetooth

What the fuck?

Position: Sticky

Nice!

otto_ortega• 10 years 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

askvictor2• 10 years ago

WebUSB and webserial are things too ( not necessarily implemented yet)

Ajedi323• 10 years ago

Not to mention WebVR, Web Payments, the Presentation API, the Gamepad API, and the Web Speech API.

ramenmeal• 10 years ago

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

iso-8859-1• 10 years ago

Probably, since position:fixed works: http://jsfiddle.net/brettadamsga/yeAhU/

r721• 10 years ago

FLAC support seems to be merged to M-56 too:

https://bugs.chromium.org/p/chromium/issues/detail?id=93887

kinlan2• 10 years ago

Funnily, I managed to get this prioristed by eng when we realised it was already backed into ChromeOS by someone tweeting me :)

cpeterso• 10 years 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

Sephr2• 10 years 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).

catmanjan2• 10 years 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.

Tushon• 10 years 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.

kuschku8• 10 years ago

Not everyone can get whitelisted from the domain creation limits of LE.

rogerdpack4• 10 years ago

The only problem is if those subdomains have a password input field "somewhere" on their sites, AFAICT. Or are you referring to google's "later" plans to add a red exclamation point "insecure" flag to the url bar for all HTTP pages?

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.

Buge4• 10 years ago

Sephr was talking about wildcard certificates, which Let's Encrypt doesn't offer. But dynamically requested certificates can sometimes be used as a replacement for wildcard certificates.

byuu6• 10 years ago

I doubt most will even go that far. You can pretty much expect those that won't go HTTPS (for whatever reason, and there are many) to change their input type="password" fields to input type="text" fields.

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.

davidgerard2• 10 years ago

What are free sites that give every user a subdomain for their profile/site/etc supposed to do?

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.

kuschku8• 10 years ago

The entire argument is about sites where that is not possible.

Lets Encrypt has a limit of 20 domains per week for you.

So you end up with at most a few hundred users.

xg15• 10 years ago

What are free sites that give every user a subdomain for their profile/site/etc supposed to do?

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.

garblegarble• 10 years ago

Couldn't you include an ACME request for a new subdomain certificate into the "create account" script?

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

clinta• 10 years ago

And that leak isn't constrained to the CA. Due to certificate transparency, that information is visible to anyone who cares to look for it.

raesene62• 10 years ago

I'm not sure I'd call ~$50/year ( e.g. https://cheapsslsecurity.co.uk/comodo/positivessl-wildcard.h...) a "huge monetary subscription fee"....

byuu6• 10 years ago

I would. That's the same price as a year of hosting an entire VPS instance with 1TB bandwidth a month, 40GB SSD storage, and 512MB of RAM. And for what? A completely automated process that loads a page on your site, verifies a META tag is present, runs an openssl command, and prints the output to a webpage for you.

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.

bjacobel2• 10 years ago

AWS Certificate Manager will give you a free wildcard if your site is hosted behind Cloudfront or on an ELB.

Latty• 10 years ago

I mean, those sites are insecure. Google has a responsibility to the user of the browser, not the site owner. If you want people to trust your site, you have to provide them the security to do so.

darinf• 10 years 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• 10 years ago

modeless• 10 years 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• 10 years 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• 10 years 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• 10 years ago

Agree, especially since early mobile browsers had exactly that feature. Is it patent-encumbered or what is the problem?

johndoe45892• 10 years 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/ work on HostGator with a shared shell access (not administrative), anybody knows?

k43213• 10 years 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• 10 years 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.

k43213• 10 years 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".

mtgx• 10 years 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?

outsidetheparty2• 10 years 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... -- 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• 10 years 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.

outsidetheparty2• 10 years ago

Those are... pretty darn good examples, actually. Thanks!

mkonecny• 10 years 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.

baybal22• 10 years 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• 10 years 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.

Kadin2• 10 years 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• 10 years ago

On iOS, you can just download a content blocker in the App Store and it'll just work in safari.

twism• 10 years ago

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

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

Related Stories