Intent to deprecate (and then remove) AppCache on insecure origins
17.559 visualizações
Pular para a primeira mensagem não lida
Joel Weinberger
8 de jan. de 2016, 17:29:5208/01/2016
para blink-dev
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
Joel Weinberger
8 de jan. de 2016, 17:33:5908/01/2016
para blink-dev, Mike West, Joshua Bell
Also, if you'd like to know the precise numbers and how I calculated it (and you're privileged to that info), feel free to contact me offline.
--Joel
Rick Byers
8 de jan. de 2016, 19:11:1308/01/2016
para Joel Weinberger, Mike West, Joshua Bell, blink-dev
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
Joel Weinberger
15 de jan. de 2016, 17:35:0615/01/2016
para Rick Byers, Mike West, Joshua Bell, blink-dev
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.
* Clear out existing AppCaches on insecure origins, plus a console message that this is being done.
--Joel
PhistucK
15 de jan. de 2016, 17:38:1815/01/2016
para Joel Weinberger, Rick Byers, Mike West, Joshua Bell, blink-dev
Will feature detection work?
"applicationCache" in window // should return false
☆PhistucK
--
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.
Joel Weinberger
15 de jan. de 2016, 17:39:4315/01/2016
para PhistucK, Rick Byers, Mike West, Joshua Bell, blink-dev
Great point. Yes, it should be removed from the window object completely, not just marked as undefined.
Joshua Bell
15 de jan. de 2016, 17:56:4715/01/2016
para Joel Weinberger, Rick Byers, Mike West, blink-dev
By "throw an error when the manifest attribute is used in a document in a non-secure context" do you mean log a deprecation error to the console? This wouldn't in itself cause an actual exception to be thrown in any script context, correct?
Joel Weinberger
15 de jan. de 2016, 17:58:2315/01/2016
para Joshua Bell, Rick Byers, Mike West, blink-dev
Well, I was imagining throwing an exception, but I guess I don't know what's standard in similar cases. If it's more appropriate to just fail and to give a deprecation message in the console, then I'm fine with that. I guess that's equivalent to the "feature not present" case, so that would make sense as the way to go.
Dominic Cooney
17 de jan. de 2016, 21:03:0917/01/2016
para Joel Weinberger, Joshua Bell, Rick Byers, Mike West, blink-dev
I think authors using appcache will typically write the manifest attribute in their HTML, like this:
<html manifest="foo.appcache">
as opposed to manipulating the manifest attribute via script. (I believe "manifest" is only effective when it is processed by the parser?) There's a wrinkle with throwing an exception in this case: because there's no JavaScript executing when the parser processes the manifest attribute, there's nowhere to throw the exception *to*. We could invoke the page's onerror handlers, but it is unlikely any have been set up yet.
When you make this change, you might need to disable the appcache, preload scanner integration. That should be < one line in HTMLPreloadScanner.cpp.
Rick Byers
18 de jan. de 2016, 17:46:5918/01/2016
para Joel Weinberger, PhistucK, Mike West, Joshua Bell, blink-dev
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.
Today window.applicationCache is always an ApplicationCache instance on Chrome, right? This change seems like it could be pretty breaking - throwing an exception and breaking page functionality in arbitrary ways (eg. what if it's common to have a bunch of app-cache code under a Chrome UA check). This design certainly seems the cleanest, so I'm happy to see you give it a shot, but you'd need to collect some compat data that indicates this isn't likely to impact many page views. We could brainstorm separately about how to do that (eg. you could use cluster telemetry to load the top 10k websites with and without this feature and look for new exceptions).
I was expecting that we'd probably have to do something uglier but more pragmatic to avoid serious compat impact. Eg. could you provide a "neutered" ApplicationCache instance that would observably behave just like a real object but not actually do any persistent caching?
It would be nice to know what Firefox was thinking here. They've got some more app compat testing infrastructure than we do, perhaps they've already done some work to understand what forms of removal are possibly web compatible?
On Fri, Jan 15, 2016 at 2:38 PM PhistucK <phis...@gmail.com> wrote:Will feature detection work?"applicationCache" in window // should return false
On Fri, Jan 15, 2016 at 5:39 PM, Joel Weinberger <j...@chromium.org> wrote:
Great point. Yes, it should be removed from the window object completely, not just marked as undefined.
I agree this is preferable to the value 'undefined'. But from other discussions we've had with the bindings team, I think that may be hard to implement (the window prototype is baked into the V8 snapshot IIRC).
Elliott Sprehn
18 de jan. de 2016, 19:32:5818/01/2016
para Rick Byers, Joel Weinberger, Mike West, PhistucK, blink-dev, Joshua Bell
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.
andrea.g...@gmail.com
19 de jan. de 2016, 01:47:1319/01/2016
para blink-dev, j...@google.com
> Making the whole API missing doesn't seem developer or platform friendly.
Agreed, plus it's not about "preferable" ... if the accessor will return undefined but `"applicationCache" in window` will return true we'll be in clown-town.
Please do not repeat mistakes like these [1]
Thank you
Mike West
19 de jan. de 2016, 03:38:0719/01/2016
para Elliott Sprehn, Rick Byers, Joel Weinberger, PhistucK, blink-dev, Joshua Bell
On Tue, Jan 19, 2016 at 1:32 AM, Elliott Sprehn <esp...@chromium.org> wrote:
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.
The specific example of appcache to the side, I've been talking with folks about the general behavior we'd like APIs to specify for themselves: https://github.com/heycam/webidl/pull/65 captures most of that conversation. The tendency at the moment is towards hiding the bits and pieces that are locked to secure contexts; if you're unhappy with that resolution, then please do weigh in. :)
-mike
Philip Jägenstedt
19 de jan. de 2016, 11:11:5919/01/2016
para Mike West, Elliott Sprehn, Rick Byers, Joel Weinberger, PhistucK, blink-dev, Joshua Bell
As Anne points out in that issue, it's not certain that adding [SecureContext] to existing APIs will be web compatible, but if it could be shown to be safe for window.applicationCache, especially given that Firefox will attempt full removal.
What are the other alternatives? Expiring the whole cache and then never updating it again sounds like it carries lower risk, but there's still some risk, as presumably sites can depend on the many states and events on ApplicationCache, and faking all of that isn't an option.
P.S. I manually added this to https://bit.ly/blinkintents, the script is picky about the title format
Philip Jägenstedt
2 de fev. de 2016, 06:03:1802/02/2016
para Mike West, Elliott Sprehn, Rick Byers, Joel Weinberger, PhistucK, blink-dev, Joshua Bell
So, perhaps we don't need to block the deprecation on knowing the exact method of removal, at least if there's a separate Intent to Remove down the line.
However, it would be nice to decide on the timeframe, so that the deprecation message can include it. Is AppCache blocking other useful work, or would it be fine to leave it deprecated for 3-6 months? Migrating to Service Worker could be a lot of work, so giving plenty of time would be nice. The Firefox documentation says only "will be removed in the future", do you know anything about their timeline?
Philip
Joel Weinberger
2 de fev. de 2016, 14:58:3702/02/2016
para Philip Jägenstedt, Mike West, Elliott Sprehn, Rick Byers, PhistucK, blink-dev, Joshua Bell
Hi everyone. I met with the API owners today, and here are a few updates.
As a clarification to the numbers I cited in the original email, the AppCache.MainPageLoad event is counted for all response retrievals from the AppCache. So this includes all resources loaded via AppCache instead of hitting the network. It does not measure the use of any of the AppCache JS APIs, but that's OK since all resource loads are done implicitly via the cache. This, I believe, is another indicator that the numbers I cited originally are a large overcount since it's taking resource loads over page loads (rather than "this page has 1 or more resources loaded via AppCache" over page loads).
The conclusion from the meeting was two fold:
- Add a deprecation message immediately for the insecure use of AppCache.
- In 2 or 3 releases, we will proceed with disabling AppCache on insecure origins. We will do so by simply not loading resources from the AppCache when the origin is insecure. We will *not* disable the APIs themselves since that has the potential to more greatly break applications, and in theory, sites should be prepared to handle a case where the AppCache is empty anyway. We will additionally add a message to the console to tell developers what is going on.
As a side note, unfortunately, I do not know about the actual Firefox timeline. I will ping Mozilla security folks and try to find out.
--Joel
Chris Harrelson
2 de fev. de 2016, 15:51:0602/02/2016
para Joel Weinberger, Philip Jägenstedt, Mike West, Elliott Sprehn, Rick Byers, PhistucK, blink-dev, Joshua Bell
This plan LGTM1.
--
Dimitri Glazkov
2 de fev. de 2016, 15:52:3002/02/2016
para Chris Harrelson, Joel Weinberger, Philip Jägenstedt, Mike West, Elliott Sprehn, Rick Byers, PhistucK, blink-dev, Joshua Bell
LGTM2.
:DG<
Michael Nordman
2 de fev. de 2016, 15:53:0002/02/2016
para Joel Weinberger, Philip Jägenstedt, Mike West, Elliott Sprehn, Rick Byers, PhistucK, blink-dev, Joshua Bell
A point of clarification, there is only one AppCache.MainPageLoad event per document load. The main document and each nested iframe add to the count, things like scripts, css, images do not add to the count. I don't know if that changes any decision making, just making the clarification.
--
Rick Byers
2 de fev. de 2016, 15:57:5902/02/2016
para Michael Nordman, Joel Weinberger, Philip Jägenstedt, Mike West, Elliott Sprehn, PhistucK, blink-dev, Joshua Bell
Given that this change shouldn't break anything (other than offline support not working), I don't think the exact usage is too relevant.
LGTM3
Joel Weinberger
2 de fev. de 2016, 17:14:1702/02/2016
para Rick Byers, Michael Nordman, Philip Jägenstedt, Mike West, Elliott Sprehn, PhistucK, blink-dev, Joshua Bell
Ah, thanks Michael! That is a useful clarification and means that the original numbers I cited are probably not that far off from reality.
--Joel
Joel Weinberger
2 de fev. de 2016, 17:20:1002/02/2016
para Rick Byers, Michael Nordman, Philip Jägenstedt, Mike West, Elliott Sprehn, PhistucK, blink-dev, Joshua Bell
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
Matt Falkenhagen
2 de fev. de 2016, 22:28:2602/02/2016
para Joel Weinberger, Rick Byers, Michael Nordman, Philip Jägenstedt, Mike West, Elliott Sprehn, PhistucK, blink-dev, Joshua Bell
2016-02-03 7:19 GMT+09:00 Joel Weinberger <j...@chromium.org>:
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
Service workers shipped in Firefox 44 <https://developer.mozilla.org/en-US/Firefox/Releases/44>, and a deprecation notice for AppCache was added <https://bugzilla.mozilla.org/show_bug.cgi?id=1204581>.
Joe Medley
3 de fev. de 2016, 11:08:4303/02/2016
para Matt Falkenhagen, Joel Weinberger, Rick Byers, Michael Nordman, Philip Jägenstedt, Mike West, Elliott Sprehn, PhistucK, blink-dev, Joshua Bell, Dru Knox
I see 3 LGTMs. Can someone please provide a tracking bug and status entry.
Thank you,
Joel Weinberger
3 de fev. de 2016, 12:20:0503/02/2016
para Joe Medley, Matt Falkenhagen, Rick Byers, Michael Nordman, Philip Jägenstedt, Mike West, Elliott Sprehn, PhistucK, blink-dev, Joshua Bell, Dru Knox
Currently mid transit, but will do once I land.
Joe Medley
22 de fev. de 2016, 13:04:0422/02/2016
para Joel Weinberger, Matt Falkenhagen, Rick Byers, Michael Nordman, Philip Jägenstedt, Mike West, Elliott Sprehn, PhistucK, blink-dev, Joshua Bell, Dru Knox
Joel,
Did you remember to do this?
Joe
Joel Weinberger
22 de fev. de 2016, 13:06:4822/02/2016
para Joe Medley, Matt Falkenhagen, Rick Byers, Michael Nordman, Philip Jägenstedt, Mike West, Elliott Sprehn, PhistucK, blink-dev, Joshua Bell, Dru Knox
It is not done yet. I got confirmation last week from the WebView folks that they don't expect any breakage on their end, so I will put together a CL this week to do it.
--Joel
Joel Weinberger
22 de fev. de 2016, 20:04:4922/02/2016
para Joe Medley, Matt Falkenhagen, Rick Byers, Michael Nordman, Philip Jägenstedt, Mike West, Elliott Sprehn, PhistucK, blink-dev, Joshua Bell, Dru Knox
Ah, Joe, perhaps I misunderstood you. Were you referring to your earlier request specifically for a tracking bug and status entry? The tracking bug is now filed as https://crbug.com/588931. For the other insecure origin deprecations and removals, we've been using the single https://www.chromestatus.com/features/6021277022158848 feature, but perhaps we should file an explicit one for this?
--Joel
Joe Medley
23 de fev. de 2016, 11:56:1023/02/2016
para Joel Weinberger, Matt Falkenhagen, Rick Byers, Michael Nordman, Philip Jägenstedt, Mike West, Elliott Sprehn, PhistucK, blink-dev, Joshua Bell, Dru Knox, Paul Kinlan
Joel,
Thank you for the tracking bug.
I'm neither the expert nor the arbiter or launch review procedures. My personal opinion is that this needs it's own dashboard item to give developers a proper and courteous heads-up.
Joe
If an API's not documented it doesn't exist.
Rick Byers
23 de fev. de 2016, 11:58:5723/02/2016
para Joe Medley, Joel Weinberger, Matt Falkenhagen, Michael Nordman, Philip Jägenstedt, Mike West, Elliott Sprehn, PhistucK, blink-dev, Joshua Bell, Dru Knox, Paul Kinlan
Yeah it's generally best to err on the side of creating new chromestatus.com entries. Developers DO check chromestatus to see "what's been added/removed in this release" and it does seed our other outreach processes (blog post, etc.).
Joel Weinberger
23 de fev. de 2016, 12:11:4623/02/2016
para Rick Byers, Joe Medley, Matt Falkenhagen, Michael Nordman, Philip Jägenstedt, Mike West, Elliott Sprehn, PhistucK, blink-dev, Joshua Bell, Dru Knox, Paul Kinlan
Okay, I'll make a new tracking bug for "Removing Old Powerful Features from Insecure Origins." I'll post back here shortly.
PhistucK
23 de fev. de 2016, 12:19:0823/02/2016
para Joel Weinberger, Rick Byers, Joe Medley, Matt Falkenhagen, Michael Nordman, Philip Jägenstedt, Mike West, Elliott Sprehn, blink-dev, Joshua Bell, Dru Knox, Paul Kinlan
I think they meant that you create one specifically for AppCache...
☆PhistucK
Joel Weinberger
23 de fev. de 2016, 12:22:1423/02/2016
para PhistucK, Rick Byers, Joe Medley, Matt Falkenhagen, Michael Nordman, Philip Jägenstedt, Mike West, Elliott Sprehn, blink-dev, Joshua Bell, Dru Knox, Paul Kinlan
Well, I already created one for general removal of powerful features on insecure origins :-) https://www.chromestatus.com/feature/5635223400218624
Happy to create more specific ones if that's what people feel are appropriate, although it seems like if we keep that general one up to date, we should be able to point people there, no?
Rick Byers
23 de fev. de 2016, 12:27:4123/02/2016
para Joel Weinberger, PhistucK, Joe Medley, Matt Falkenhagen, Michael Nordman, Philip Jägenstedt, Mike West, Elliott Sprehn, blink-dev, Joshua Bell, Dru Knox, Paul Kinlan
The problem is that people and our tools/process browse over the list of eg. "what's exactly changed in Chrome 48". The main UI is sorted by milestone (with links to each milestone) for this reasons. I don't have a super strong opinion though, but in other instances we've erred on creating really light weight entries for specific changes per-milestone (just make sure there are links to the details with more information).
Rick
Joel Weinberger
23 de fev. de 2016, 12:31:0123/02/2016
para Rick Byers, PhistucK, Joe Medley, Matt Falkenhagen, Michael Nordman, Philip Jägenstedt, Mike West, Elliott Sprehn, blink-dev, Joshua Bell, Dru Knox, Paul Kinlan
Thanks for the clarification. I'll remove that feature and add a specific one for AppCache deprecation and removal.
Joel Weinberger
23 de fev. de 2016, 12:36:2723/02/2016
para Rick Byers, PhistucK, Joe Medley, Matt Falkenhagen, Michael Nordman, Philip Jägenstedt, Mike West, Elliott Sprehn, blink-dev, Joshua Bell, Dru Knox, Paul Kinlan
Here is the AppCache specific status: https://www.chromestatus.com/feature/5714236168732672
Joe Medley
23 de fev. de 2016, 12:36:5123/02/2016
para Joel Weinberger, Rick Byers, PhistucK, Matt Falkenhagen, Michael Nordman, Philip Jägenstedt, Mike West, Elliott Sprehn, blink-dev, Joshua Bell, Dru Knox, Paul Kinlan
Joel,
Thank you for doing that. I hope you don't feel beat up.
Joe
If an API's not documented it doesn't exist.
Joel Weinberger
23 de fev. de 2016, 12:40:4623/02/2016
para Joe Medley, Rick Byers, PhistucK, Matt Falkenhagen, Michael Nordman, Philip Jägenstedt, Mike West, Elliott Sprehn, blink-dev, Joshua Bell, Dru Knox, Paul Kinlan
Not at all. I may have over-coffee'd this moring, and so the caffeine may have gotten me to work too quickly on that first Chrome Feature Status :-)
Joel Weinberger
24 de fev. de 2016, 21:12:3924/02/2016
para Joe Medley, Rick Byers, PhistucK, Matt Falkenhagen, Michael Nordman, Philip Jägenstedt, Mike West, Elliott Sprehn, blink-dev, Joshua Bell, Dru Knox, Paul Kinlan
FYI, the AppCache deprecation warning just landed in https://codereview.chromium.org/1723353002/.
--Joel
Michael Nordman
26 de fev. de 2016, 18:47:0926/02/2016
para Joel Weinberger, Joe Medley, Rick Byers, PhistucK, Matt Falkenhagen, Philip Jägenstedt, Mike West, Elliott Sprehn, blink-dev, Joshua Bell, Dru Knox, Paul Kinlan
I haven't replied to Luis yet. I'm not sure what to tell him :(
---------- 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
A mensagem foi excluída
juliod...@gmail.com
30 de mar. de 2016, 17:01:4130/03/2016
para blink-dev, j...@chromium.org, jme...@google.com, rby...@google.com, phis...@gmail.com, fal...@chromium.org, phi...@opera.com, mk...@google.com, esp...@chromium.org, jsb...@chromium.org, dk...@google.com, paulk...@google.com
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 )
- 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.
Joel Weinberger
30 de mar. de 2016, 18:40:5730/03/2016
para juliod...@gmail.com, blink-dev, jme...@google.com, rby...@google.com, phis...@gmail.com, fal...@chromium.org, phi...@opera.com, mk...@google.com, esp...@chromium.org, jsb...@chromium.org, dk...@google.com, paulk...@google.com
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.
std...@utah.gov
4 de abr. de 2016, 12:03:2704/04/2016
para blink-dev, j...@google.com
Are there any plans to deprecate and remove app cache for secure origins? Just wondering how soon we need to start looking at service workers. Thx
On Friday, January 8, 2016 at 3:29:52 PM UTC-7, Joel Weinberger wrote:
On Friday, January 8, 2016 at 3:29:52 PM UTC-7, Joel Weinberger wrote:
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
Joel Weinberger
4 de abr. de 2016, 12:07:2304/04/2016
para std...@utah.gov, blink-dev
To my knowledge, we do not have such plans. However, since that's a different discussion, I'd recommend starting a new thread with that as the subject to make sure the right people are able to answer your question.
--Joel
t...@timniblett.net
5 de abr. de 2016, 04:36:3805/04/2016
para blink-dev, juliod...@gmail.com, jme...@google.com, rby...@google.com, phis...@gmail.com, fal...@chromium.org, phi...@opera.com, mk...@google.com, esp...@chromium.org, jsb...@chromium.org, dk...@google.com, paulk...@google.com
I like to use static websites with AppCache and/or Service Worker. I'm quite resigned to the idea of using SSL, given the security issues I've read about. I'd like to point out, though, that removing AppCache from insecure origins makes Google Cloud Storage (GCS) even more unusable (can't use Service Workers at the moment) for static sites as there is, AFAIK, no way to set up a static site on GCS over SSL, which is a shame.
However all is not lost as it IS possible to use Amazon S3 over SSL via CloudFront. I guess I'm impressed that you're willing to sacrifice your business in order to provide increased security for the community more generally.
Tim
PhistucK
5 de abr. de 2016, 04:46:2005/04/2016
para t...@timniblett.net, blink-dev, juliod...@gmail.com, Joe Medley, Rick Byers, Matt Falkenhagen, Philip Jägenstedt, Mike West, Elliott Sprehn, Joshua Bell, Dru Knox, Paul Kinlan
On Tue, Apr 5, 2016 at 11:36 AM, <t...@timniblett.net> wrote:
AFAIK, no way to set up a static site on GCS over SSL, which is a shame.
https://www.googleapis.com/download/storage/v1/b/chromium-browser-snapshots/o/Win%2F100012%2Fchrome-win32-syms.zip?generation=1&alt=media seems to work, for example. Perhaps you refer to a different configuration?
☆PhistucK
juliod...@gmail.com
5 de abr. de 2016, 05:54:0705/04/2016
para blink-dev, juliod...@gmail.com, jme...@google.com, rby...@google.com, phis...@gmail.com, fal...@chromium.org, phi...@opera.com, mk...@google.com, esp...@chromium.org, jsb...@chromium.org, dk...@google.com, paulk...@google.com
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, ....
So, please stop that and my clients and i will be happy.
Or find a solution for http, e.g. : let appcache only work if the client is offline! otherwise let client get requests online.
I'm french, so sorry if my english is not perfect.
Joel Weinberger
5 de abr. de 2016, 10:36:4105/04/2016
para juliod...@gmail.com, blink-dev, jme...@google.com, rby...@google.com, phis...@gmail.com, fal...@chromium.org, phi...@opera.com, mk...@google.com, esp...@chromium.org, jsb...@chromium.org, dk...@google.com, paulk...@google.com
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.
juliod...@gmail.com
5 de abr. de 2016, 13:26:2205/04/2016
para blink-dev, juliod...@gmail.com, jme...@google.com, rby...@google.com, phis...@gmail.com, fal...@chromium.org, phi...@opera.com, mk...@google.com, esp...@chromium.org, jsb...@chromium.org, dk...@google.com, paulk...@google.com
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.
Ok it could do the trick but if i have to do that on all PCs of all my clients, it's not finish.. And it seems there are remaining issues on that: https://bugs.chromium.org/p/chromium/issues/detail?id=561820.
- 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.
If you want.. but for intranet apps and a network restricted by IP...It's not everyday. And it seems HTTPS cannot garenty that:: https://blog.heckel.xyz/2013/07/01/how-to-use-mitmproxy-to-read-and-modify-https-traffic-of-your-phone/.
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?"
Good read and it's certainly much lower than i expected, but installation, update of cert, update of the app are always here.
- 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
My problem is not HTTPS, the problem is that old apps will be broken by your decision to remove appcache. ( I don't say anything for service worker because service worker has always been for https, so it's not a pb )
I prefer you put the adresse bar in red with the biggest alert of the world in the middle of the page and let old apps continue to work instead of break all these apps.
Rick Byers
5 de abr. de 2016, 13:30:1005/04/2016
para juliod...@gmail.com, blink-dev, Joe Medley, PhistucK Productions, Matt Falkenhagen, Philip Jägenstedt, Mike West, Elliott Sprehn, Joshua Bell, Dru Knox, Paul Kinlan
Being very careful / thoughtful in breaking old apps is absolutely important (and one of the main jobs of this intent process). Can you elaborate on how you expect apps to be "broken"?
Our thinking was that by neutering appcache, the apps would behave like existing first launch / cache cleared scenarios, so the risk of "real breakage" was minimal. Of course they won't work offline in scenarios they used to, which could certainly be considered a form of "breakage". Is that all though, or is there something more we're missing?
Christian Biesinger
5 de abr. de 2016, 14:02:2505/04/2016
para juliod...@gmail.com, blink-dev, Joe Medley, Rick Byers, PhistucK Productions, Matt Falkenhagen, Philip Jägenstedt, Mike West, Elliott Sprehn, Joshua Bell, Dru Knox, paulk...@google.com
> And it seems HTTPS cannot garenty that:: https://blog.heckel.xyz/2013/07/01/how-to-use-mitmproxy-to-read-and-modify-https-traffic-of-your-phone/.
Oh come on, that requires installing the CA certificate for mitmproxy.
Of course under such circumstances there are no guarantees. But that's
a pretty specialized case, and not normal operation.
-Christian
juliod...@gmail.com
5 de abr. de 2016, 14:40:0705/04/2016
para blink-dev, juliod...@gmail.com, jme...@google.com, phis...@gmail.com, fal...@chromium.org, phi...@opera.com, mk...@google.com, esp...@chromium.org, jsb...@chromium.org, dk...@google.com, paulk...@google.com, rby...@google.com
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.
Rick Byers
5 de abr. de 2016, 15:12:4305/04/2016
para juliod...@gmail.com, blink-dev, Joe Medley, PhistucK Productions, Matt Falkenhagen, Philip Jägenstedt, Mike West, Elliott Sprehn, Joshua Bell, Dru Knox, Paul Kinlan
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).
juliod...@gmail.com
5 de abr. de 2016, 17:56:3405/04/2016
para blink-dev, juliod...@gmail.com, jme...@google.com, phis...@gmail.com, fal...@chromium.org, phi...@opera.com, mk...@google.com, esp...@chromium.org, jsb...@chromium.org, dk...@google.com, paulk...@google.com, rby...@google.com
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).
Joel Weinberger
6 de abr. de 2016, 07:15:0406/04/2016
para juliod...@gmail.com, blink-dev, jme...@google.com, phis...@gmail.com, fal...@chromium.org, phi...@opera.com, mk...@google.com, esp...@chromium.org, jsb...@chromium.org, dk...@google.com, paulk...@google.com, rby...@google.com
Rick: Unfortunately, a chrome://flags entry is not sufficient as it also requires simultaneous use of --user-data-dir to specify a new profile directory so cookie jars aren't shared. We were just discussing in the Twittersphere the other day that we probably should have a DevTools button that has the same effect as --unsafely-treat-insecure-origin-as-secure + --user-data-dir without restarting Chrome, so I just filed https://crbug.com/600974 to track this request.
On Tue, Apr 5, 2016 at 10:56 PM <juliod...@gmail.com> wrote:
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
I've verified that the combination of --unsafely-treat-insecure-origin-as-secure and --user-data-dir was able to get getUserMedia() to work on an insecure origin for me, so I'm not sure what's going on 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
I'm not sure. I thought there was a way for command line flags to be set by an enterprise policy, but I do not know how that works.
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).
This seems awfully heavy handed for a very, very small population, especially when we already offer the command line option. As a cynic, I also suspect that this wouldn't ween anyone off of insecure origins; it would just cause developers to become dependent on this option. If we really think this is a case worth worrying about, I would vastly prefer to just delay the removal (but I am unconvinced in the value of this case).
juliod...@gmail.com
6 de abr. de 2016, 08:29:5306/04/2016
para blink-dev, juliod...@gmail.com, jme...@google.com, phis...@gmail.com, fal...@chromium.org, phi...@opera.com, mk...@google.com, esp...@chromium.org, jsb...@chromium.org, dk...@google.com, paulk...@google.com, rby...@google.com
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 ??
PhistucK
6 de abr. de 2016, 08:40:3606/04/2016
para Julien t, blink-dev, Joe Medley, Matt Falkenhagen, Philip Jägenstedt, Mike West, Elliott Sprehn, Joshua Bell, Dru Knox, Paul Kinlan, Rick Byers
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?
☆PhistucK
juliod...@gmail.com
6 de abr. de 2016, 08:54:0406/04/2016
para blink-dev, juliod...@gmail.com, jme...@google.com, fal...@chromium.org, phi...@opera.com, mk...@google.com, esp...@chromium.org, jsb...@chromium.org, dk...@google.com, paulk...@google.com, rby...@google.com
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...
Joel Weinberger
6 de abr. de 2016, 08:54:3606/04/2016
para PhistucK, Julien t, blink-dev, Joe Medley, Matt Falkenhagen, Philip Jägenstedt, Mike West, Elliott Sprehn, Joshua Bell, Dru Knox, Paul Kinlan, Rick Byers
On Wed, Apr 6, 2016 at 1:40 PM PhistucK <phis...@gmail.com> wrote:
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
I'm pretty sure that's your issue.
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 ??
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.
Joel Weinberger
6 de abr. de 2016, 08:56:1106/04/2016
para juliod...@gmail.com, blink-dev, jme...@google.com, fal...@chromium.org, phi...@opera.com, mk...@google.com, esp...@chromium.org, jsb...@chromium.org, dk...@google.com, paulk...@google.com, rby...@google.com
On Wed, Apr 6, 2016 at 1:54 PM <juliod...@gmail.com> wrote:
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 )
Good catch. Fixed now.
But there is always the yellow warning...
Yes, that's because it's very unsafe.
juliod...@gmail.com
6 de abr. de 2016, 09:30:4806/04/2016
para blink-dev, phis...@gmail.com, juliod...@gmail.com, jme...@google.com, fal...@chromium.org, phi...@opera.com, mk...@google.com, esp...@chromium.org, jsb...@chromium.org, dk...@google.com, paulk...@google.com, rby...@google.com
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.
Yes you have the choice, you can send a bad signal to devs removing features in a short delay or analyse real study case as https://blog.yell.com/2016/03/https-is-hard/ to take a good decision.
Thank you for your assistance, now i have to work ;)
Have a nice day!
t...@timniblett.net
6 de abr. de 2016, 18:09:3506/04/2016
para blink-dev, t...@timniblett.net, juliod...@gmail.com, jme...@google.com, rby...@google.com, fal...@chromium.org, phi...@opera.com, mk...@google.com, esp...@chromium.org, jsb...@chromium.org, dk...@google.com, paulk...@google.com
Yes, excuse my imprecision, I meant serving over a custom domain. Its easy enough with HTTP but not HTTPS. Using a Google domain is not of any interest to me, or to most people setting up a static website I suspect. I was interested in GCS as it seemed (in principle) simpler than S3 + CloudFront as the edge cache is seamless...
I think Google are missing a trick here. There _is_ a case for HTTPS everywhere, in which case why not make it trivially easy and totally automated.
This is difficult Institutionally perhaps as it requires bringing together CA and Domain Registrar, together with a robust identity mechanism.
Let's Encrypt gets half way there in terms of automation. Setting up a Domain Name Registrar to go the other half of the way looks like an opportunity. If I had to bet it would be on Amazon rather than Google, as GCS already seems a bit of a dog's breakfast -- it doesn't work properly with App Engine as I found to my cost a few months ago, so my confidence in Google getting its act together has taken a knock.
Tim
bdm.w...@gmail.com
3 de mai. de 2016, 08:32:4103/05/2016
para blink-dev, j...@google.com
ramy.he...@gmail.com
23 de jul. de 2016, 02:39:1023/07/2016
para blink-dev, j...@google.com
rahulti...@gmail.com
27 de jul. de 2016, 15:40:5927/07/2016
para blink-dev, j...@google.com
Today I updated my browser to chrome 52 and bizarre things started to happen related to application cache.
Here is my case :
I had deployed two instances of my application with IP:
I have configured my app manifest file to cache my minified javascipt file all-classes.js.
Now after re-deployment of new code i.e. all-classes.js file for these two instances and making changes to app manifest file, my latest all-classes.js file is not being downloaded by chrome and old file is served from chrome cache only causing trouble in application running but since I have updated my manifest file, shouldn't it download latest all-classes.js file.
Any idea is this related to this deprecation of application cache feature in chrome 52 or is anything I am missing here which u can help me with.
Chris Harrelson
27 de jul. de 2016, 16:09:5527/07/2016
para rahulti...@gmail.com, blink-dev, Joel Weinberger
--
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.
Michael Nordman
27 de jul. de 2016, 17:03:2227/07/2016
para rahulti...@gmail.com, blink-dev, Joel Weinberger
The feature should still be functioning. The http cache control headers on the manifest file can affect appcache updates. If its long lived in the http cache, the appcache update will see that cached resource. If you clear your http cache and then the appcache updates as expected, that would suggest the problem has to do with the http headers on the manifest file.
On Wed, Jul 27, 2016 at 12:40 PM, <rahulti...@gmail.com> wrote:
specp...@gmail.com
3 de ago. de 2016, 07:11:4103/08/2016
para blink-dev, j...@google.com
https://santa-bro.ru почему пишит ошибка 403?
суббота, 9 января 2016 г., 4:29:52 UTC + 6 пользователь Джоэл Вайнбергер написал:
суббота, 9 января 2016 г., 4:29:52 UTC + 6 пользователь Джоэл Вайнбергер написал:
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
rahulti...@gmail.com
5 de ago. de 2016, 02:31:3605/08/2016
para blink-dev, rahulti...@gmail.com, j...@google.com, mich...@chromium.org
We are facing very serious issue related to Application cache trying to understand the browsers behaviour in this context :
Request headers are different when we access application in normal mode and incognito mode. as in Attached screenshot.
why is this difference?
PhistucK
5 de ago. de 2016, 03:17:5305/08/2016
para Rahul Tiwari, blink-dev, Joel Weinberger, Michael Nordman
On Fri, Aug 5, 2016 at 9:31 AM, <rahulti...@gmail.com> wrote:
Request headers are different when we access application in normal mode and incognito mode. as in Attached screenshot.why is this difference?
Intent threads are not meant for bug reports. Please, move this report to crbug.com.
☆PhistucK
kiss31...@gmail.com
27 de out. de 2016, 18:03:0827/10/2016
para blink-dev
是的！您說的沒錯確實一直是有兩個人在使用，而起頭是我先發現有架構管理，因為我真的不懂也不會設定、誤以為是能幫我用好哪些繁雜系統，所以想嘗試看看…結果，我還是學不會就放棄丟著！直到今年初我用原本的gmail帳號ashley00312分享推特，導致有心人強取奪權拿走我全部帳號導致無法使用，“連動我行動門號偽裝我本人”…自行刪除創辦各項帳戶；還自行傳改發行app下載器……。我以求助無門了，因為我一直被攔截網域、通訊，連電信公司都說沒遇過如此事件！這些發現是我今年4/12~10/27每天自己不眠不休才找出問題答案，以上所言如有謊稱本人施盈竹將願受一切法律責任！
seatt...@gmail.com
29 de out. de 2016, 19:29:4729/10/2016
para blink-dev, j...@google.com
You IDEOTS, how many people care about your intra-circle of Blah. My screen says, you may be unsecue. Well do something about it!!!!!!!!!!!
John Osseward Jr
29 de out. de 2016, 19:32:3329/10/2016
para blink-dev
Now how many people do you think understand the bull shit you have put on my screen!!!! 1 in a 1,000,000!!!
--
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.
nguyenviet...@gmail.com
7 de nov. de 2016, 08:58:5807/11/2016
para blink-dev, j...@google.com
Vào 05:29:52 UTC+7 Thứ Bảy, ngày 09 tháng 1 năm 2016, Joel Weinberger đã viết:
bitul...@gmail.com
17 de nov. de 2016, 20:38:1917/11/2016
para blink-dev, j...@google.com
s.servicios...@gmail.com
10 de fev. de 2017, 00:19:4210/02/2017
para blink-dev, j...@google.com
A mensagem foi excluída
smith...@gmail.com
6 de mar. de 2017, 02:10:5506/03/2017
para blink-dev, j...@google.com
A mensagem foi excluída
ads...@calibre-ebook.com
1 de jun. de 2017, 23:59:0501/06/2017
para blink-dev, j...@google.com
Please do not remove Appcache. I am the developer of calibre (https://calibre-ebook.com) an open source ebook management program. calibre includes a http server that allows its users to access the books over the air. One of the typical use cases of the server is to run it on your personal home desktop/laptop and connect to it using a phone/tablet and read books. The server uses application cache to enable offline access. I deliberately chose application cache over service workers, despite the deprecation, as many of calibre's (approx. 3 million) users are unsophisticated and would not be able to acquire a domain/setup SSL certificates, etc. just to transfer books to their devices. If you insist on removing Application Cache you will essentially force me to move to creating dedicated application for use on iOS/Android instead of using a browser. That is a shame.
In general, for the use case of private servers, requiring HTTPS for offline capability is simply not appropriate. Please consider that browsers are used for more than just accessing public websites.
Thank you.
ads...@calibre-ebook.com
2 de jun. de 2017, 00:30:0602/06/2017
para blink-dev, j...@google.com, ads...@calibre-ebook.com
As a compromise that both increases the security of browsing public
websites, while not unduly penalising the ability of ordinary users to
run private servers, you could only disable appcache when the port for the
http connection is 80 and leave it enabled for HTTP connections on
other ports.
mylyn...@gmail.com
10 de jun. de 2017, 20:35:3210/06/2017
para blink-dev, j...@google.com
how can I fix this problem?
adalbe...@gmail.com
11 de jun. de 2017, 12:50:3911/06/2017
para blink-dev, j...@google.com, Adalberto Romero
jos...@yahoo.com
11 de jun. de 2017, 13:08:0911/06/2017
para blink-dev, j...@google.com, adalbe...@gmail.com
How about getting user permission?
[Warning popup]
This webpage is attempting to install web scripts into your browser. If you were not expecting this action, please choose DENY for your security.
[Allow AppCache] [Deny Appcache]
PhistucK
11 de jun. de 2017, 14:16:5311/06/2017
para Josh K, blink-dev, jww, adalbe...@gmail.com
Yeah... Users click through dialogs and have no idea what scripts are.
☆PhistucK
--
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+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/02cd31f8-864b-42ba-9eb9-c79d20865376%40chromium.org.
jos...@yahoo.com
11 de jun. de 2017, 14:29:1011/06/2017
para blink-dev, jos...@yahoo.com, j...@google.com, adalbe...@gmail.com
With that logic we should make the internet illegal to protect our citizens.
On Sunday, June 11, 2017 at 1:16:53 PM UTC-5, PhistucK wrote:
Yeah... Users click through dialogs and have no idea what scripts are.
☆PhistucK
On Sun, Jun 11, 2017 at 8:08 PM, joshk03 via blink-dev <blin...@chromium.org> wrote:
How about getting user permission?[Warning popup]This webpage is attempting to install web scripts into your browser. If you were not expecting this action, please choose DENY for your security.[Allow AppCache] [Deny Appcache]
--
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.
PhistucK
11 de jun. de 2017, 16:37:1311/06/2017
para Josh K, blink-dev, jww, adalbe...@gmail.com
We probably should, but it has become too popular that we cannot deprecate now. So the least browsers can do is to make it as safe as possible while using the most simple terms and not asking non-technical people technical questions they will never understand. The web should just work safely. :)
☆PhistucK
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/29ff6a37-0d27-46d3-b86d-cb2a9afba1f7%40chromium.org.
jos...@yahoo.com
11 de jun. de 2017, 19:14:5711/06/2017
para blink-dev, jos...@yahoo.com, j...@google.com, adalbe...@gmail.com
Then I have a feature request for Microsoft to get up to speed with the new paradigm...
[User Account Control]
Do you want to allow this app to make changes to your device? Too bad. Here at corporate headquarters we decided nobody will be allowed to install apps, ever. Get over it. And don't forget to buy our new tablet later this year. It checks email so much better than this device.
On Sunday, June 11, 2017 at 3:37:13 PM UTC-5, PhistucK wrote:
We probably should, but it has become too popular that we cannot deprecate now. So the least browsers can do is to make it as safe as possible while using the most simple terms and not asking non-technical people technical questions they will never understand. The web should just work safely. :)
☆PhistucK
On Sun, Jun 11, 2017 at 9:29 PM, joshk03 via blink-dev <blin...@chromium.org> wrote:
With that logic we should make the internet illegal to protect our citizens.--
On Sunday, June 11, 2017 at 1:16:53 PM UTC-5, PhistucK wrote:Yeah... Users click through dialogs and have no idea what scripts are.☆PhistucKOn Sun, Jun 11, 2017 at 8:08 PM, joshk03 via blink-dev <blin...@chromium.org> wrote:--How about getting user permission?[Warning popup]This webpage is attempting to install web scripts into your browser. If you were not expecting this action, please choose DENY for your security.[Allow AppCache] [Deny Appcache]
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/02cd31f8-864b-42ba-9eb9-c79d20865376%40chromium.org.
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/29ff6a37-0d27-46d3-b86d-cb2a9afba1f7%40chromium.org.
tmgs...@gmail.com
22 de set. de 2017, 23:10:4622/09/2017
para blink-dev, j...@google.com
preethi...@gmail.com
15 de nov. de 2017, 20:20:5615/11/2017
para blink-dev, j...@google.com
kyo...@gmail.com
14 de mar. de 2019, 11:39:2214/03/2019
para blink-dev, j...@google.com
My blogsite www.ilblogdimikima49.myblog.it is now blocked because Chrome report it as a "privacy error". This is a problem for me. The main site under which it was created is https://www.virgilio.it/ but my blog is not considered safe.
Ryan Hamilton
14 de mar. de 2019, 11:57:1014/03/2019
para kyo...@gmail.com, blink-dev, Joel Weinberger
The error, if you click advanced, says "This server could not prove that it is www.ilblogdimikima49.myblog.it; its security certificate is from *.myblog.it. This may be caused by a misconfiguration or an attacker intercepting your connection."
You site is reachable just fine at https://ilblogdimikima49.myblog.it/
Cheers,
Ryan
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bb34f59a-b287-4975-9e04-5e42e61bbe12%40chromium.org.
faisalal...@gmail.com
16 de mar. de 2020, 12:40:4016/03/2020
para blink-dev, j...@google.com
why its is work todaty
Responder a todos
Responder ao autor
Encaminhar
0 nova mensagem