Are you proposing that the window.applicationCache API won't exist for documents loaded from an insecure origin? Or just that the manifest wont be fetched and the API would be neutered somehow? Other than not working offline, what failure modes would you expect?
Rick
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
On Sat, Jan 16, 2016 at 12:34 AM, Joel Weinberger <j...@chromium.org> wrote:Sorry for the delayed response! My proposal is to return an undefined object when window.applicationCache is accessed on a non-secure context (plus give a console message) and to throw an error when the manifest attribute is used in a document in a non-secure context. This would mimic, as closely as possible, what we've done with getUserMedia() and geolocation. I'm certainly open to other suggestions, though.There is an open question about explicitly clearing out already existing AppCaches in insecure origins as well. I would lean towards doing that just to be explicit about it, but that's certainly up for debate.Thus, the failure modes I expect would be:* Failure to register a manifest in a non-secure context, plus a thrown error.* An undefined reference returned when window.applicationCache is accessed on an insecure origin, plus a console message.
On Fri, Jan 15, 2016 at 2:38 PM PhistucK <phis...@gmail.com> wrote:Will feature detection work?"applicationCache" in window // should return false
Great point. Yes, it should be removed from the window object completely, not just marked as undefined.
Indeed, I'd rather we made it just expire the contents of the cache immediately and log a warning to the console.
Making the whole API missing doesn't seem developer or platform friendly.
> Making the whole API missing doesn't seem developer or platform friendly.
Indeed, I'd rather we made it just expire the contents of the cache immediately and log a warning to the console.
Making the whole API missing doesn't seem developer or platform friendly.
--
--
Also, one further clarification: Looking at the Firefox bug for removing AppCache (https://bugzilla.mozilla.org/show_bug.cgi?id=1237782), it appears that although they do not have an explicit deadline for removing AppCache, it is mostly blocked on shipping Service Workers. Once that happens, they plan on putting together a more definite timeline.--Joel
Currently mid transit, but will do once I land.
---------- Forwarded message ----------
From: Fasterworks | Diseño web & Comunicación Visual <faste...@gmail.com>
Date: Thu, Feb 18, 2016 at 6:30 AM
Subject: Application cache
To: mich...@chromium.org
Hello,
I've read Application Cache API is going to be deprecated, it works great in my phone and desktop, I love it, it's simple to use and works great! Do you know it it's going to be disabled soon in Chrome? I don't understand why, it is good for me! I love it.
Thank you,
Luis
Please stop that immediatly.I think that's a very bad decision for these reasons:- This decision don't resolve the problem, this will just push users to come back to IE to use their app.
- I think it's not your(chrome team) job to decide or not if a service have to be secure or not, it's the job of the app owner, think about intranet apps wich don't need SSL!
- App cache is young (5/6 years) and was the unique way to do offlines app, so many apps made few years ago aren't in SSL.- Independant devs will have to explain to their clients, why the app they made few months ago will not work with chrome anymore or they have to pay. ( very bad for confidence in the web platform )
Firefox recently announced an intent to remove AppCache entirely: https://www.fxsitecompat.com/en-US/docs/2016/application-cache-support-will-be-removed/While it seems awfully aggressive to straight up remove AppCache immediately, it has been a long source of consternation to the security team that AppCache is allowed over insecure origins. This allows for potentially persistent, online and offline, XSS of sites, which is a pretty serious privilege escalation from regular XSS.In the spirit of Deprecating Powerful Features on Insecure Origins, we are proposing to deprecate and then remove AppCache on insecure origins. I'd like to add a deprecation message ASAP, and then in a release or two, do the actual disabling.Unfortunately, we don't have perfect numbers for usage at the moment, since there isn't a proper WebCore.FeatureObserver entry for AppCache. However, doing some rough math using WebCore.FeatureObserver.PageVisits and AppCache.MainPageLoad entries, it appears that around 1.9% of all page loads use include an AppCache main page load event, but only 0.05% do that over an insecure origin. While not quite at the 0.03% level we'd like it to be, I'd also point out that this is a really, really rough estimate since the PageVisits and MainPageLoad events are not from the same measurement positions in the Chrome stack.Thoughts?--Joel
AFAIK, no way to set up a static site on GCS over SSL, which is a shame.
Thanks for the input. I've inlined some responses below.On Wed, Mar 30, 2016 at 2:01 PM <juliod...@gmail.com> wrote:Please stop that immediatly.I think that's a very bad decision for these reasons:- This decision don't resolve the problem, this will just push users to come back to IE to use their app.That is certainly the users choice to make, although Mozilla, for example, is moving towards a similar policy.
- I think it's not your(chrome team) job to decide or not if a service have to be secure or not, it's the job of the app owner, think about intranet apps wich don't need SSL!I respectfully disagree. We (the User Agent) are best placed to make security-by-default for users, and the W3C's Priority of Constituencies makes it clear that we have a responsibility to users before developers.
To your particular point about "intranet apps", we do consider localhost to be "secure" even without SSL, so hopefully that will help testing. However, generalizing that to "intranet apps" is not necessarily safe. There are many intranets where someone less-trusted is present on the network, and HTTPS is critical in providing end-to-end protection.
- App cache is young (5/6 years) and was the unique way to do offlines app, so many apps made few years ago aren't in SSL.- Independant devs will have to explain to their clients, why the app they made few months ago will not work with chrome anymore or they have to pay. ( very bad for confidence in the web platform )Let's Encrypt is an example of one of several services that provide free-of-cost SSL certificates, so they don't necessarily have to pay.
Ok SSL is a good thing, but please don't do that for all theses reasons.
Thanks for reply, let me answer ;).
Le jeudi 31 mars 2016 00:40:57 UTC+2, Joel Weinberger a écrit :Thanks for the input. I've inlined some responses below.On Wed, Mar 30, 2016 at 2:01 PM <juliod...@gmail.com> wrote:Please stop that immediatly.I think that's a very bad decision for these reasons:- This decision don't resolve the problem, this will just push users to come back to IE to use their app.That is certainly the users choice to make, although Mozilla, for example, is moving towards a similar policy.I know but have you read the comments of this link ? And have you read the comment of the intent to remove bug at mozilla ? https://bugzilla.mozilla.org/show_bug.cgi?id=1237782 , i think the consensus is not here ,by far.- I think it's not your(chrome team) job to decide or not if a service have to be secure or not, it's the job of the app owner, think about intranet apps wich don't need SSL!I respectfully disagree. We (the User Agent) are best placed to make security-by-default for users, and the W3C's Priority of Constituencies makes it clear that we have a responsibility to users before developers.If you go there you will have to host all apps of the world on google's server to be sure the server's owners is not been hacked ? The user is warned when he is connected to a non-secure network, he is also warned when he consult a non-https app that's not secure, i think your job is already done.(https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/DHQLv76QaEM%5B1-25%5D )To your particular point about "intranet apps", we do consider localhost to be "secure" even without SSL, so hopefully that will help testing. However, generalizing that to "intranet apps" is not necessarily safe. There are many intranets where someone less-trusted is present on the network, and HTTPS is critical in providing end-to-end protection.Yes but intranet apps are not on http://localhost in real life, so http://my-super-app/ is ok ?
- App cache is young (5/6 years) and was the unique way to do offlines app, so many apps made few years ago aren't in SSL.- Independant devs will have to explain to their clients, why the app they made few months ago will not work with chrome anymore or they have to pay. ( very bad for confidence in the web platform )Let's Encrypt is an example of one of several services that provide free-of-cost SSL certificates, so they don't necessarily have to pay.Yes i know let-encrypt, but even the cert is free, in real life there is a cost : update the app to be compatible with https ( client and server side), CPU overhead, maintenance to renew the cert, have a dedicated server, less performance for client.....
- Please let Service worker be more stable and cross browser before break app cache(even on insecure origin !).Ok SSL is a good thing, but please don't do that for all theses reasons.To finish SSL don't resolve the problem : https://www.quora.com/Is-MITM-attack-possible-when-on-HTTPS, http://thehackernews.com/2016/01/free-ssl-certificate-malware.html, ....
On Tue, Apr 5, 2016 at 10:54 AM <juliod...@gmail.com> wrote:Thanks for reply, let me answer ;).
Le jeudi 31 mars 2016 00:40:57 UTC+2, Joel Weinberger a écrit :Thanks for the input. I've inlined some responses below.On Wed, Mar 30, 2016 at 2:01 PM <juliod...@gmail.com> wrote:Please stop that immediatly.I think that's a very bad decision for these reasons:- This decision don't resolve the problem, this will just push users to come back to IE to use their app.That is certainly the users choice to make, although Mozilla, for example, is moving towards a similar policy.I know but have you read the comments of this link ? And have you read the comment of the intent to remove bug at mozilla ? https://bugzilla.mozilla.org/show_bug.cgi?id=1237782 , i think the consensus is not here ,by far.- I think it's not your(chrome team) job to decide or not if a service have to be secure or not, it's the job of the app owner, think about intranet apps wich don't need SSL!I respectfully disagree. We (the User Agent) are best placed to make security-by-default for users, and the W3C's Priority of Constituencies makes it clear that we have a responsibility to users before developers.If you go there you will have to host all apps of the world on google's server to be sure the server's owners is not been hacked ? The user is warned when he is connected to a non-secure network, he is also warned when he consult a non-https app that's not secure, i think your job is already done.(https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/DHQLv76QaEM%5B1-25%5D )To your particular point about "intranet apps", we do consider localhost to be "secure" even without SSL, so hopefully that will help testing. However, generalizing that to "intranet apps" is not necessarily safe. There are many intranets where someone less-trusted is present on the network, and HTTPS is critical in providing end-to-end protection.Yes but intranet apps are not on http://localhost in real life, so http://my-super-app/ is ok ?I actually didn't complete my original paragraph, sorry! Besides treating localhost as a secure origin, we also provide the --unsafely-treat-insecure-origin-as-secure flag, which allows you to temporarily specify an origin that should be treated as secure, even if it isn't. It should be useful for exactly this problem.
- App cache is young (5/6 years) and was the unique way to do offlines app, so many apps made few years ago aren't in SSL.- Independant devs will have to explain to their clients, why the app they made few months ago will not work with chrome anymore or they have to pay. ( very bad for confidence in the web platform )Let's Encrypt is an example of one of several services that provide free-of-cost SSL certificates, so they don't necessarily have to pay.Yes i know let-encrypt, but even the cert is free, in real life there is a cost : update the app to be compatible with https ( client and server side), CPU overhead, maintenance to renew the cert, have a dedicated server, less performance for client.....There's also a cost to Real World HTTP, namely that your users have no guarantees whatsoever that the content they're seeing at your origin is in any way the content you intend to be present.
Also, the HTTPS costs you're referring to are almost certainly much lower than you'd expect. See https://istlsfastyet.com/ for more information, and especially the section title, "TLS operational costs are still higher, right?"
- Please let Service worker be more stable and cross browser before break app cache(even on insecure origin !).Ok SSL is a good thing, but please don't do that for all theses reasons.To finish SSL don't resolve the problem : https://www.quora.com/Is-MITM-attack-possible-when-on-HTTPS, http://thehackernews.com/2016/01/free-ssl-certificate-malware.html, ....HTTPS provides a minimum bar for us to even be discussing security. It's not a silver bullet, but it's a baseline
Thanks for explanations, i'm really aware and concerned of that, and until now i implemented https only for apps that required a high level of security, but for other apps i kept simplicity and avoid costs.For the future all my apps will be under https.But if you remove appcache on insecure origin in chrome 52(in 3 months as i seen), it's not possible for me to refactor and update ~10 apps in 3 months and explain to customers why they have to update their apps.The flag --unsafely-treat-insecure-origin-as-secure could help but when i test it for getusermedia(), it doesn't do anything and the warning "Use of the Application Cache is deprecated on insecure origins. " is always here. Even if i set a new profile as mentionned here
(https://www.chromium.org/Home/chromium-security/deprecating-powerful-features-on-insecure-origins).This only display me a warning at the launch of chrome in french "Vous utilisez un indicateur de ligne commande non pris en charge --unsafely-treat-insecure-origin-as-secure".I use chrome beta.So, the proposal you done to Joel could help devs to do the switch to https, if not please give us more time(1/2 years).
Le mardi 5 avril 2016 21:12:43 UTC+2, Rick Byers a écrit :On Tue, Apr 5, 2016 at 2:40 PM, <juliod...@gmail.com> wrote:Thank you for your reply Rick.When I make an offline app for a client, it's simply because the client need to use the app in offline mode when he can't access to the net.Example :
- Morning : The user is at office and synchronize its planning for the day.
- All Day: The user is outside of his office and open the app on his tabletor laptop(icon added by "Add to homescreen"*1), to do his work: do an expertise, check something, take photos, etc, and all that is stored in local storage or indexeddb.
- Evening: The user come back to office and synchronize all the data to the serveur.
Thanks for the clarification - it is just the offline capability we're talking about here.Are you at all concerned about this potential additional step?
- Afternoon: The user connects to WiFi at a coffee shop (or happens near an Evil Twin access point). An attacker provides a service at your URL ("http://mycorpapp/") and so your application happily synchronizes all the data to this attacker-controlled server, and potentially downloads a modified version of the app which modifies the stored data (so that when your server sees it later, it's been tampered with).
It's attacks like this that make offline support via un-encrypted HTTP fundamentally dangerous for users. So, although we really don't want to "break" legitimate apps (and will bend over backwards to maximize web compatibility), we are willing to accept disabling some rare scenarios for the benefit of substantial privacy/security improvement for all users.Joel, is there any way for an administrator or user to set --unsafely-treat-insecure-origin-as-secure for Chrome on Android? Is it worth
considering some switch to help ease the migration burden here for enterprise customers? Eg. maybe a frighteningly-named chrome://flags entry to permit AppCache on http for awhile (similar to how we eliminated NPAPI in a phased fashion?). Or maybe more granularly by providing some mechanism which AppCache can be enabled on http for a specified set of origins (again all as temporary transition mechanisms - to reduce the risk of surprise emergencies in cases like this). Even while there is some manual opt-out, we'll get most of the security benefits here (since >99.99% of users will never request the opt-out).
Example: When i set these flags :"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --unsafely-treat-insecure-origin-as-secure="simpl.info" --user-data-dir=/test/only/profile/dir
I get:
What i'm doing wrong ?
An origin includes the protocol, I believe. So -"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --unsafely-treat-insecure-origin-as-secure="http://simpl.info" --user-data-dir=/test/only/profile/dir
Does that work?☆PhistucKOn Wed, Apr 6, 2016 at 3:29 PM, <juliod...@gmail.com> wrote:Example: When i set these flags :"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --unsafely-treat-insecure-origin-as-secure="simpl.info" --user-data-dir=/test/only/profile/dir
I get:
What i'm doing wrong ?
Also i can now say it's not a solution, because of the lost of user profile.I you remove features in 3 months, how can devs trust in new features as service worker ? Fiction: if one day https is replaced by httpx, do you will also remove service worker under https in 3 months ??
Yes that work with the protocol, thanks :). ( it was not the case here: https://www.chromium.org/Home/chromium-security/deprecating-powerful-features-on-insecure-origins )
But there is always the yellow warning...
I you remove features in 3 months, how can devs trust in new features as service worker ? Fiction: if one day https is replaced by httpx, do you will also remove service worker under https in 3 months ??
Sure. No matter what we do, the number of months will be "too short" for some people. Any number of months is arbitrary. You request 6 months, but why is that fundamentally different from 3 months? And if someone else comes to us tomorrow and says "all we need is 9 months", why should your 6 months be the limit? No matter what we do, there's going to be a cutoff.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Firefox недавно объявила о намерении удалить AppCache полностью: https:. // WWW fxsitecompat.com/en-US/docs/ 2016 / приложение-cache- поддержка-будет-быть удалены /Хотя это кажется ужасно агрессивным по отношению к прямо удалить AppCache немедленно, это было долго источник испуга к команде безопасности, которая AppCache допускается по незащищенным происхождения. Это позволяет потенциально стойкие, онлайн и оффлайн, XSS сайтов, который является довольно серьезной привилегий от обычного XSS.В духе протестующий мощных функций на ненадежном Origins , мы предлагаем , чтобы принизить , а затем удалить AppCache на ненадежном происхождения. Я хотел бы, чтобы добавить сообщение устаревания как можно скорее, а затем в пресс - релизе или два, сделать фактическое отключение.К сожалению, мы не имеем совершенные числа для использования в данный момент, так как не является надлежащим запись WebCore.FeatureObserver для AppCache. Однако, делая некоторые грубые математику с помощью WebCore.FeatureObserver. PageVisits и AppCache.MainPageLoad записи, оказывается , что около 1,9% всей страницы нагрузок используют следующее главное событие загрузки страницы AppCache, но только 0,05% сделать это через незащищенное происхождения. Хотя не совсем на уровне 0,03% мы хотели бы , чтобы это было, я бы также отметить, что это на самом деле, действительно грубая оценка , так как PageVisits и события MainPageLoad не из одних и тех же позиций измерения в стеке Chrome.Мысли?--Joel
Request headers are different when we access application in normal mode and incognito mode. as in Attached screenshot.why is this difference?
--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/UKF8cK0EwMI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+unsubscribe@chromium.org.