Intent to deprecate (and then remove) AppCache on insecure origins

6174 wyświetlenia
Przejdź do pierwszej nieodczytanej wiadomości

Joel Weinberger

nieprzeczytany,
8 sty 2016, 17:29:528.01.2016
do 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

nieprzeczytany,
8 sty 2016, 17:33:598.01.2016
do 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

nieprzeczytany,
8 sty 2016, 19:11:138.01.2016
do 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

nieprzeczytany,
15 sty 2016, 17:35:0615.01.2016
do 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

nieprzeczytany,
15 sty 2016, 17:38:1815.01.2016
do 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

nieprzeczytany,
15 sty 2016, 17:39:4315.01.2016
do 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

nieprzeczytany,
15 sty 2016, 17:56:4715.01.2016
do 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

nieprzeczytany,
15 sty 2016, 17:58:2315.01.2016
do 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

nieprzeczytany,
17 sty 2016, 21:03:0917.01.2016
do 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

nieprzeczytany,
18 sty 2016, 17:46:5918.01.2016
do 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

nieprzeczytany,
18 sty 2016, 19:32:5818.01.2016
do 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

nieprzeczytany,
19 sty 2016, 01:47:1319.01.2016
do 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

nieprzeczytany,
19 sty 2016, 03:38:0719.01.2016
do 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

nieprzeczytany,
19 sty 2016, 11:11:5919.01.2016
do 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

nieprzeczytany,
2 lut 2016, 06:03:182.02.2016
do 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

nieprzeczytany,
2 lut 2016, 14:58:372.02.2016
do 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

nieprzeczytany,
2 lut 2016, 15:51:062.02.2016
do Joel Weinberger, Philip Jägenstedt, Mike West, Elliott Sprehn, Rick Byers, PhistucK, blink-dev, Joshua Bell
This plan LGTM1.

--

Dimitri Glazkov

nieprzeczytany,
2 lut 2016, 15:52:302.02.2016
do Chris Harrelson, Joel Weinberger, Philip Jägenstedt, Mike West, Elliott Sprehn, Rick Byers, PhistucK, blink-dev, Joshua Bell
LGTM2.

:DG<

Michael Nordman

nieprzeczytany,
2 lut 2016, 15:53:002.02.2016
do 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

nieprzeczytany,
2 lut 2016, 15:57:592.02.2016
do 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

nieprzeczytany,
2 lut 2016, 17:14:172.02.2016
do 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

nieprzeczytany,
2 lut 2016, 17:20:102.02.2016
do 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

nieprzeczytany,
2 lut 2016, 22:28:262.02.2016
do 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

nieprzeczytany,
3 lut 2016, 11:08:433.02.2016
do 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,


Joe Medley | Technical Writer, DevPlat | jme...@google.com | 816-678-7195

Joel Weinberger

nieprzeczytany,
3 lut 2016, 12:20:053.02.2016
do 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

nieprzeczytany,
22 lut 2016, 13:04:0422.02.2016
do 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

Joe Medley | Technical Writer, DevPlat | jme...@google.com | 816-678-7195

Joel Weinberger

nieprzeczytany,
22 lut 2016, 13:06:4822.02.2016
do 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

nieprzeczytany,
22 lut 2016, 20:04:4922.02.2016
do 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

nieprzeczytany,
23 lut 2016, 11:56:1023.02.2016
do 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

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195
If an API's not documented it doesn't exist.

Rick Byers

nieprzeczytany,
23 lut 2016, 11:58:5723.02.2016
do 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

nieprzeczytany,
23 lut 2016, 12:11:4623.02.2016
do 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

nieprzeczytany,
23 lut 2016, 12:19:0823.02.2016
do 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

nieprzeczytany,
23 lut 2016, 12:22:1423.02.2016
do 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

nieprzeczytany,
23 lut 2016, 12:27:4123.02.2016
do 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

nieprzeczytany,
23 lut 2016, 12:31:0123.02.2016
do 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

nieprzeczytany,
23 lut 2016, 12:36:2723.02.2016
do 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

Unfortunately, I can't figure out how to delete an old feature, so if anyone can point me in the right direction, I'd love to get rid of the over-general status I created: https://www.chromestatus.com/feature/5635223400218624

Joe Medley

nieprzeczytany,
23 lut 2016, 12:36:5123.02.2016
do 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

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195
If an API's not documented it doesn't exist.

Joel Weinberger

nieprzeczytany,
23 lut 2016, 12:40:4623.02.2016
do 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

nieprzeczytany,
24 lut 2016, 21:12:3924.02.2016
do 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

nieprzeczytany,
26 lut 2016, 18:47:0926.02.2016
do 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
Wiadomość została usunięta

juliod...@gmail.com

nieprzeczytany,
30 mar 2016, 17:01:4130.03.2016
do 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

nieprzeczytany,
30 mar 2016, 18:40:5730.03.2016
do 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

nieprzeczytany,
4 kwi 2016, 12:03:274.04.2016
do 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:
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

nieprzeczytany,
4 kwi 2016, 12:07:234.04.2016
do 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

nieprzeczytany,
5 kwi 2016, 04:36:385.04.2016
do 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

nieprzeczytany,
5 kwi 2016, 04:46:205.04.2016
do 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.  




PhistucK

juliod...@gmail.com

nieprzeczytany,
5 kwi 2016, 05:54:075.04.2016
do 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.



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

nieprzeczytany,
5 kwi 2016, 10:36:415.04.2016
do 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.


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

nieprzeczytany,
5 kwi 2016, 13:26:225.04.2016
do 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.


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

nieprzeczytany,
5 kwi 2016, 13:30:105.04.2016
do 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

nieprzeczytany,
5 kwi 2016, 14:02:255.04.2016
do 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
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

On Tue, Apr 5, 2016 at 1:26 PM, <juliod...@gmail.com> wrote:
>>>>

juliod...@gmail.com

nieprzeczytany,
5 kwi 2016, 14:40:075.04.2016
do 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

nieprzeczytany,
5 kwi 2016, 15:12:435.04.2016
do 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).