You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by "Homer, Tony" <to...@intel.com> on 2014/11/01 21:28:35 UTC
Re: [iOS 8] WKWebView moving forward
I started looking at how to make the camera plugin be able to work in
WKWebView.
Before, I had mentioned intercepting resource requests as a way to fix the
file:// requests.
However, WKWebView does not offer a way to intercept resource requests so
that won’t work.
:/
Andrew had suggested introducing some proxy paths as a way to deal with
the path problems, which seems fine.
On the other hand, the request handlers could just inspect the path in the
request and do the right thing - are the proxy paths needed?
I think implicit in those comments was a suggestion that the affected
plugins such as camera could return URLs using those paths.
The thing about changing camera and file plugins to support localhost that
bothers me, is that now those core plugins effectively support a non-core
plugin.
Also, other (on-cordova) plugins that depend on file protocol will be
incompatible with the local web server wkwebview solution (unless they
make changes to support it).
I wonder if it would be better to handle this in CDVPluginResult?
A hook could be added to initWithStatus and exposed to plugins.
Then the SALocalWebServer plugin can use the hook to inspect the message
and fix it, if it is a file:// URL.
So, for example, when camera calls CDVPluginResult
resultWithStatus:messageAsString and passes in a file URL, SALocalServer
can get a chance to inspect and modify the result – changing it to an
http:localhost URL. It could simply replace the file protocol with
http://localhost:port, then the handler could decode the path before
building the response.
This is ugly, but it would prevent the need to change the camera and file
and should allow other non-cordova plugins that depend on file:// URLs to
work.
Tony
On 10/31/14, 2:03 PM, "Homer, Tony" <to...@intel.com> wrote:
>I started with cookies in my POC, but I was concerned about replay
>attacks.
>I couldn’t think of a way to avoid replay vulnerability with cookies
>(without SSL), so I was going to switch to the side channel approach I
>tried to describe. Do you think replay vulnerability is irrelevant? I’m
>not a security guy, so I wasn’t sure if it mattered or not. That’s
>actually one of the things I was hoping to get feedback about.
>
>I guess I don’t follow how CORS relates to the camera plugin, does it use
>XHR? Maybe you can elaborate?
>I expect I’ll see it when I try the camera plugin from WKWebView, just
>didn’t get around to it yet.
>The only thing that jumps out at me is that you get a file:// url back -
>we could change that.
>Or maybe intercept file:// requests in the plugin? If it’s just a path
>problem, maybe we could intercept the request, fix the path, then respond
>with the right thing...
>
>Tony
>
>On 10/31/14, 1:19 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
>
>>Unless you're having the server proxy requests to remote sites, I don't
>>think CORS headers are necessary.
>>
>>Tony - awesome stuff! absolutely doing it right. More technical-focused
>>discussion the better :). Using cookies seems the best way to me since
>>that
>>covers all requests. Adding headers works only for XHRs.
>>
>>On Fri, Oct 31, 2014 at 12:12 PM, Kirk Shoop (MS OPEN TECH) <
>>Kirk.Shoop@microsoft.com> wrote:
>>
>>> Yes, the handler should be able to add CORS headers to its responses
>>>that
>>> will enable requests from any origin.
>>>
>>> For instance adding 'Access-Control-Allow-Origin: *' would allow any
>>> origin to make a request from the local server.
>>> http://www.w3.org/TR/cors/#access-control-allow-origin-response-header
>>>
>>> Similarly Access-Control-Allow-Methods and Access-Control-Allow-Headers
>>> could be used to define valid requests.
>>>
>>> Kirk
>>>
>>> Developer
>>> Microsoft Open Technologies, Inc.
>>>
>>> -----Original Message-----
>>> From: Homer, Tony [mailto:tony.homer@intel.com]
>>> Sent: Friday, October 31, 2014 8:40 AM
>>> To: dev@cordova.apache.org
>>> Subject: Re: [iOS 8] WKWebView moving forward
>>>
>>> Last night I added a handler to the Local Web Server plugin that
>>>returns
>>> 403 for non-localhost requests.
>>> The handler also has a prototype token system to restrict requests to
>>>the
>>> app, but I need to change the approach a bit.
>>> Currently I set a cookie and the handler just checks for the cookie and
>>> returns 403 if it is missing.
>>> This is susceptible to replay attacks from backgrounded apps - not sure
>>>if
>>> that is important or not.
>>>
>>> I¹m going to investigate adding a map to the plugin, then add an entry
>>>for
>>> every request.
>>> The entry will be a hash of the request and a random number.
>>>
>>> I¹ll have to wire up support for overriding url loads so that I can add
>>> the header with the random number to the request.
>>> Then the request handler will look the entry up in the map and remove
>>>it -
>>> this should eliminate re-playability.
>>>
>>> I¹m not sure about the CORS issue with camera pluginŠ I¹ll be curious
>>>to
>>> test it - maybe it could be addressed by modifying the response in the
>>> GCDWebServer handler?
>>>
>>> Tony
>>>
>>> P.S. This is my first attempt participating in discussion on the list -
>>> let me know if I¹m doing it wrong!
>>> Am I wasting my time investigating this? Should I just leave it
>>>Shazron?
>>>
>>> On 10/30/14, 9:52 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
>>>
>>> >On Thu, Oct 30, 2014 at 5:05 PM, Shazron <sh...@gmail.com> wrote:
>>> >
>>> >> The port conflict situation has been solved with the latest version
>>> >>of the plugin. Passing in a port of "0" will choose a random port.
>>> >>More details in the plugin's README.md
>>> >>
>>> >Awesome! Why even allow a non-random port?
>>> >Also learned today that in chrome, webcrypto API is disabled for http
>>> >origins, but enabled for https. Not sure if this is true for Safari as
>>> >well, but certainly this change will be a can of worms!
>>> >
>>> >
>>> >>
>>> >> Ouch - didn't think about Camera plugin and File plugin impact. That
>>> >>proxy thing might work, as long as there are no folder name
>>> >>collisions.
>>> >>
>>> >Prefixing all resources into a fake top-level directory will eliminate
>>> >the folder name collision problem I think.
>>> >
>>> >
>>> >>
>>> >> My point regarding mixing WKWebView and UIWebView on iOS 8 is, if
>>>you
>>> >>have a user on iOS 8.x, you want all users on that iOS version to
>>> >>have the same experience, and for bug reporting purposes.
>>> >
>>> >
>>> >> On Wed, Oct 29, 2014 at 5:11 PM, Andrew Grieve
>>><ag...@chromium.org>
>>> >> wrote:
>>> >>
>>> >> > We could restrict access to the webserver by stuffing a cookie
>>>into
>>> >>the
>>> >> > webview with an access token, then have the server just 500 on any
>>> >> request
>>> >> > missing the cookie. We should also be able to restrict external
>>> >>requests
>>> >> > just by listening on 127.0.0.1 instead of 0.0.0.0 (doesn't look
>>> >> > like GCDWebServer supports this, but we can hack it in).
>>> >> >
>>> >> > The problem of port conflicts is annoying though. Maybe we try
>>>random
>>> >> ports
>>> >> > until one works? Is there any need to use the same port for
>>>multiple
>>> >> runs?
>>> >> >
>>> >> > The CORS thing is sad, because it also means things like Camera
>>>plugin
>>> >> will
>>> >> > be broken (can't use resulting URL in <img>).
>>> >> >
>>> >> > Although we might just do (this is different than the current
>>>mapping
>>> >>in
>>> >> > the plugin):
>>> >> > http://localhost:RANDOM_PORT/www
>>> >> > http://localhost:RANDOM_PORT/asset-library
>>> >> > http://localhost:RANDOM_PORT/file-system
>>> >> >
>>> >> > to proxy the three locations.
>>> >> >
>>> >> > This also means we can't use FileEntry.toURL() and have it work,
>>> >>unless
>>> >> > toURL returns http://localhost:RANDOM_PORT/file-system/... Maybe
>>> >> that's
>>> >> > fine?
>>> >> >
>>> >> >
>>> >> > I don't think it's weird that an app will need to support
>>>WKWebView on
>>> >> some
>>> >> > OS versions, and UIWebView on others. That's already the case to
>>> >>support
>>> >> > iOS 7.
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Wed, Oct 29, 2014 at 6:22 PM, Shazron <sh...@gmail.com>
>>>wrote:
>>> >> >
>>> >> > > This does not preclude using the file url API function I
>>>suppose.
>>> >> Here's
>>> >> > a
>>> >> > > flowchart on how I think it would work:
>>> >>http://i.imgur.com/zq4zreN.png
>>> >> > >
>>> >> > >
>>> >> > > On Wed, Oct 29, 2014 at 2:48 PM, Tommy Williams
>>><tommy@devgeeks.org
>>> >
>>> >> > > wrote:
>>> >> > >
>>> >> > > > This whole thing reeks of sadness and pain.
>>> >> > > >
>>> >> > > > The security implications of this will have to be considered
>>>very
>>> >> > > > carefully.
>>> >> > > > On 29 Oct 2014 16:40, "Shazron" <sh...@apache.org> wrote:
>>> >> > > >
>>> >> > > > > ## What We Know So Far
>>> >> > > > >
>>> >> > > > > 1. Because of the file:// url loading bug, we couldn't
>>>support
>>> >>the
>>> >> > > > > WKWebView in the iOS 8 GM release. It has since been fixed,
>>>for
>>> >> > release
>>> >> > > > > post iOS 8.1 (not sure when), through a new WKWebView API
>>> >>function
>>> >> (
>>> >> > > > > http://trac.webkit.org/changeset/174029/trunk)
>>> >> > > > > 2. The alternative is embedding a local web server and
>>>serving
>>> >> assets
>>> >> > > > from
>>> >> > > > > that
>>> >> > > > >
>>> >> > > > > ## Abandon file:// url Loading API Method
>>> >> > > > >
>>> >> > > > > My proposal is, we abandon the local file:// url loading
>>>method
>>> >>in
>>> >> > (1)
>>> >> > > > > above, since it will create problems with support.
>>> >> > > > >
>>> >> > > > > For example, if we support the new local file url loading
>>>API
>>> >> > function
>>> >> > > in
>>> >> > > > > iOS 8.2.0 (speculated) -- and a user is on 8.0.2, what then?
>>>You
>>> >> > would
>>> >> > > > not
>>> >> > > > > have WKWebView support for that user, and you would use
>>> >>UIWebView
>>> >> > > > instead.
>>> >> > > > > This will just be confusing, and leads to problems.
>>> >> > > > >
>>> >> > > > > With the embedded local web server method, you can support
>>> >>**any**
>>> >> > > > version
>>> >> > > > > of iOS 8.x.
>>> >> > > > >
>>> >> > > > > ## Embrace Embedded Local Web Server Method
>>> >> > > > >
>>> >> > > > > I have a Cordova plugin that implements this, and it should
>>>work
>>> >> with
>>> >> > > > > cordova-ios 3.7.0:
>>> >> > > > > https://github.com/shazron/CordovaLocalWebServer
>>> >> > > > >
>>> >> > > > > It dynamically updates the <access> tag value when it loads,
>>> >> > overriding
>>> >> > > > it
>>> >> > > > > to the actual location and port. Since it is a plugin, it
>>>can be
>>> >> > > > swappable
>>> >> > > > > (for whatever reason).
>>> >> > > > >
>>> >> > > > > It does not solve the problem where any backgrounded app can
>>> >>access
>>> >> > our
>>> >> > > > > local web server.
>>> >> > > > >
>>> >> > > > > ## Future Steps
>>> >> > > > >
>>> >> > > > > This plugin is already working in cordova-ios 3.7.0
>>> >>(un-released,
>>> >> up
>>> >> > > next
>>> >> > > > > for vote release).
>>> >> > > > >
>>> >> > > > > The wkwebview branch:
>>> >> > > > >
>>> >> > > > > 1. Needs be rebased
>>> >> > > > > 2. Needs to be re-tested
>>> >> > > > > 3. issues in CB-7043 that relate to the wkwebview have to be
>>> >> resolved
>>> >> > > > > 4. branch presented for review to other committers
>>> >> > > > > 5. resolve any comments and issues from (4)
>>> >> > > > > 6. wkwebview branch integrated into master
>>> >> > > > >
>>> >> > > > > I will work on these items next after getting cordova-ios
>>>3.7.0
>>> >> out.
>>> >> > > Any
>>> >> > > > > help is welcome.
>>> >> > > > >
>>> >> > > > > ## Migration Issues
>>> >> > > > >
>>> >> > > > > If you are migrating to WKWebView from UIWebView, you will
>>>lose
>>> >> some
>>> >> > > > > functionality.
>>> >> > > > >
>>> >> > > > > 1. No more whitelist feature (NSURLProtocol is not supported
>>>in
>>> >> > > > WKWebView)
>>> >> > > > > 2. Your XmlHttpRequest calls now need to be CORS compliant
>>> >>(this is
>>> >> > > still
>>> >> > > > > true if loaded through a file:// url)
>>> >> > > > > 3. HTML5 offline application cache is not available in
>>> >>WKWebView (
>>> >> > > > > https://devforums.apple.com/message/1060452)
>>> >> > > > >
>>> >> > > >
>>> >> > >
>>> >> >
>>> >>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>>> For additional commands, e-mail: dev-help@cordova.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>>> For additional commands, e-mail: dev-help@cordova.apache.org
>>>
>>>
>
Re: [iOS 8] WKWebView moving forward
Posted by Kerri Shotts <ke...@photokandy.com>.
le *sigh* :-(
___________________________________
*Kerri Shotts*
photoKandy Studios, LLC
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
Update:
Xcode 6.1.1 GM seed (Nov 14th 2014) does not include the
"loadFileURL:readAccessURL:" selector in the WKWebView.h header. So the bug
fix we are waiting for most likely won't be in iOS 8.1.1
On Mon, Nov 10, 2014 at 3:30 PM, tommy-carlos williams <to...@devgeeks.org>
wrote:
> Yeah… I’ll try to report some of it and get back to you.
>
> --
> tommy-carlos williams
>
> On 11 November 2014 at 09:50:55, Shazron (shazron@gmail.com) wrote:
>
> Bug report? Or email me personally. Which ones besides the ones that will
> have problems as we discussed on this thread.
>
> On Mon, Nov 10, 2014 at 2:41 PM, tommy-carlos williams <tommy@devgeeks.org
> >
> wrote:
>
> > I had much less success… it doesn’t play well with other legacy plugins,
> > does it?
> >
> >
> >
> > --
> > tommy-carlos williams
> >
> > On 11 November 2014 at 03:00:30, Michal Mocny (mmocny@chromium.org)
> wrote:
> >
> > Success! I did indeed have to add the framework manually.
> >
> > Thanks for instructions.
> >
> > On Thu, Nov 6, 2014 at 7:49 PM, Shazron <sh...@gmail.com> wrote:
> >
> > > There have been major changes to the `wkwebview` branch of
> `cordova-ios`.
> > > The `WKWebView` functionality has been moved to a plugin in the
> > > `cordova-plugins` repo.
> > >
> > > So, for now you can do:
> > >
> > > cordova create wkwvtest test.project wkwvtest
> > > cd wkwvtest
> > > cordova platform add ios@wkwebview --usegit
> > > cordova plugin add
> > > https://github.com/apache/cordova-plugins.git#master:wkwebview-engine
> > >
> > > Modify the root `config.xml` and edit this value to:
> > >
> > > <content src="http://localhost:0" />
> > >
> > > Then:
> > >
> > > cordova emulate
> > >
> > > You might get a build error, this is a `plugman` bug that doesn't
> install
> > > `WebKit.framework` properly even though it is defined in plugin.xml.
> You
> > > might have to do a:
> > >
> > > open -a Xcode platforms/ios
> > >
> > > ...and add the framework manually.
> > >
> > > On Thu, Nov 6, 2014 at 11:15 AM, Shazron <sh...@gmail.com> wrote:
> > >
> > > > Thanks Tony - I'll look at that PR when I have some time.
> > > >
> > > > Yesterday I did some major work to isolate the webviews into plugins
> > > > (CDVWKWebViewEngine, CDVUIWebViewEngine). This way we can reduce the
> > risk
> > > > by extracting the WKWebView items into a plugin, and the core has no
> > > > dependency on WebKit.framework anymore, plus speedy (well, speedier)
> > > > updates if it needs updating. The CDVUIWebViewEngine will remain in
> the
> > > > core as the default engine. I'm still working on this, but it already
> > > works
> > > > currently. I'm abstracting things out more, and removing code from
> the
> > > > CDVViewController which has become unwieldy.
> > > >
> > > > Swapping out engines would use the preference:
> > > > <preference name="CordovaWebViewEngine" value="CDVWKWebViewEngine" />
> > > >
> > > > Any new web engine needs to implement the new
> CDVWebViewEngineProtocol
> > > > protocol, and installed as a plugin.
> > > >
> > > > On Mon, Nov 3, 2014 at 6:55 PM, Homer, Tony <to...@intel.com>
> > > wrote:
> > > >
> > > >> I have already forked it and made the changes in a topic branch.
> > > >> I was originally thinking that I would make 2 topic branches: 1 for
> > > >> localhost-only and 1 for auth tokens.
> > > >> However, after I finished the first set of changes I realized that
> the
> > > >> second set would be dependent on the first.
> > > >> I’ll submit a pull request tomorrow for you to look at - I’ll be
> happy
> > > to
> > > >> redo it as multiple branches if that makes sense.
> > > >>
> > > >> I got a little sidetracked with local web server plugin, but I’ve
> also
> > > >> forked cordova-ios and made a topic branch from wkwebview.
> > > >> I'll start working on some of the changes I proposed earlier in this
> > > >> thread tomorrow (for plugins like camera that return file:// urls,
> > > etc.).
> > > >>
> > > >> Tony
> > > >>
> > > >> On 11/3/14, 7:23 PM, "Shazron" <sh...@gmail.com> wrote:
> > > >>
> > > >> >Thanks Tony for all the investigation. Please do fork the local web
> > > >> server
> > > >> >plugin and put all your work in topic branches for eventual pull
> > > requests
> > > >> >to the main repo.
> > > >> >
> > > >> >This is precisely why the local web server is a plugin, and not in
> > the
> > > >> >core. I don't profess to be a security expert, and we can update
> this
> > > >> >plugin to cover most of the security cases or someone else can
> > provide
> > > >> >their better plugin. I don't think this needs to be bulletproof,
> not
> > > that
> > > >> >we can entirely be (has there ever been a Security Update by Apple
> > that
> > > >> >*didn't* include a WebKit vulnerability?)
> > > >> >
> > > >> >I'd like to get the cordova-ios/wkwebview branch back into the
> > mainline
> > > >> as
> > > >> >soon as possible, but under an experimental flag (--experimental ?)
> > > for
> > > >> >bin/create. This will choose a new template that has
> WebKit.framework
> > > in
> > > >> >it, which will also define a macro to conditionally compile the new
> > > bits
> > > >> >in
> > > >> >(I haven't added the macros yet in the topic branch).
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> >On Mon, Nov 3, 2014 at 7:27 AM, Homer, Tony <to...@intel.com>
> > > >> wrote:
> > > >> >
> > > >> >> I spent a lot of time thinking about ways to avoid replay attacks
> > for
> > > >> >>the
> > > >> >> local web server plugin this weekend.
> > > >> >>
> > > >> >> Specifically, I felt like there should be a way to take advantage
> > of
> > > >> the
> > > >> >> fact that the client and the server are running in the same
> > process.
> > > >> >> I thought this might enable some kind of sideband (non-http)
> > > >> >> authentication possibility.
> > > >> >> The 2 possibilities I was most interested in, but eventually
> > > concluded
> > > >> >>are
> > > >> >> not practical were:
> > > >> >> 1. unique token per http request - not practical because there is
> > no
> > > >> per
> > > >> >> http request event available
> > > >> >> 2. a whitelist of “remote” ports - not practical because there is
> > no
> > > >> >> simple way to get a list of ports in use by WKWebView
> > > >> >>
> > > >> >> After going down this rathole and coming up empty, I reconsidered
> > the
> > > >> >> original problem and came to the following conclusions.
> > > >> >> 1. restricting requests to localhost-only limits “attacks” to
> > > >> >>backgrounded
> > > >> >> apps
> > > >> >> 2. including a token in the requests will prevent backgrounded
> apps
> > > >> from
> > > >> >> being able to successfully make unwanted requests
> > > >> >> 3. the token is vulnerable to network analysis, but that cannot
> be
> > > done
> > > >> >>on
> > > >> >> device
> > > >> >>
> > > >> >> Therefore, vulnerability is limited to the case where the there
> is
> > > >> >> (1) a “hostile" app installed on device and running in the
> > background
> > > >> >>and
> > > >> >> (2) the user’s device is connected to a wi-fi network where an
> > > attacker
> > > >> >>is
> > > >> >> able to perform network analysis to capture the token.
> > > >> >> In this case, the attacker could just inspect the HTTP traffic
> > > instead
> > > >> >>of
> > > >> >> capturing the token and sending it to their backgrounded app.
> > > >> >> In other words, it seems that replay attacks are possible but not
> > > >> >>useful.
> > > >> >> If we care about the “hostile wifi network” case, we need
> something
> > > >> like
> > > >> >> SSL.
> > > >> >>
> > > >> >> On 11/1/14, 4:28 PM, "Homer, Tony" <to...@intel.com> wrote:
> > > >> >>
> > > >> >> >I started looking at how to make the camera plugin be able to
> work
> > > in
> > > >> >> >WKWebView.
> > > >> >> >Before, I had mentioned intercepting resource requests as a way
> to
> > > fix
> > > >> >>the
> > > >> >> >file:// requests.
> > > >> >> >However, WKWebView does not offer a way to intercept resource
> > > requests
> > > >> >>so
> > > >> >> >that won’t work.
> > > >> >> >:/
> > > >> >> >
> > > >> >> >Andrew had suggested introducing some proxy paths as a way to
> deal
> > > >> with
> > > >> >> >the path problems, which seems fine.
> > > >> >> >On the other hand, the request handlers could just inspect the
> > path
> > > in
> > > >> >>the
> > > >> >> >request and do the right thing - are the proxy paths needed?
> > > >> >> >I think implicit in those comments was a suggestion that the
> > > affected
> > > >> >> >plugins such as camera could return URLs using those paths.
> > > >> >> >The thing about changing camera and file plugins to support
> > > localhost
> > > >> >>that
> > > >> >> >bothers me, is that now those core plugins effectively support a
> > > >> >>non-core
> > > >> >> >plugin.
> > > >> >> >Also, other (on-cordova) plugins that depend on file protocol
> will
> > > be
> > > >> >> >incompatible with the local web server wkwebview solution
> (unless
> > > they
> > > >> >> >make changes to support it).
> > > >> >> >
> > > >> >> >I wonder if it would be better to handle this in
> CDVPluginResult?
> > > >> >> >A hook could be added to initWithStatus and exposed to plugins.
> > > >> >> >Then the SALocalWebServer plugin can use the hook to inspect the
> > > >> >>message
> > > >> >> >and fix it, if it is a file:// URL.
> > > >> >> >So, for example, when camera calls CDVPluginResult
> > > >> >> >resultWithStatus:messageAsString and passes in a file URL,
> > > >> >>SALocalServer
> > > >> >> >can get a chance to inspect and modify the result – changing it
> to
> > > an
> > > >> >> >http:localhost URL. It could simply replace the file protocol
> with
> > > >> >> >http://localhost:port, then the handler could decode the path
> > > before
> > > >> >> >building the response.
> > > >> >> >This is ugly, but it would prevent the need to change the camera
> > and
> > > >> >>file
> > > >> >> >and should allow other non-cordova plugins that depend on
> file://
> > > URLs
> > > >> >>to
> > > >> >> >work.
> > > >> >> >
> > > >> >> >
> > > >> >> >Tony
> > > >> >> >
> > > >> >> >On 10/31/14, 2:03 PM, "Homer, Tony" <to...@intel.com>
> wrote:
> > > >> >> >
> > > >> >> >>I started with cookies in my POC, but I was concerned about
> > replay
> > > >> >> >>attacks.
> > > >> >> >>I couldn’t think of a way to avoid replay vulnerability with
> > > cookies
> > > >> >> >>(without SSL), so I was going to switch to the side channel
> > > approach
> > > >> I
> > > >> >> >>tried to describe. Do you think replay vulnerability is
> > > irrelevant?
> > > >> >>I’m
> > > >> >> >>not a security guy, so I wasn’t sure if it mattered or not.
> > That’s
> > > >> >> >>actually one of the things I was hoping to get feedback about.
> > > >> >> >>
> > > >> >> >>I guess I don’t follow how CORS relates to the camera plugin,
> > does
> > > it
> > > >> >>use
> > > >> >> >>XHR? Maybe you can elaborate?
> > > >> >> >>I expect I’ll see it when I try the camera plugin from
> WKWebView,
> > > >> just
> > > >> >> >>didn’t get around to it yet.
> > > >> >> >>The only thing that jumps out at me is that you get a file://
> url
> > > >> >>back -
> > > >> >> >>we could change that.
> > > >> >> >>Or maybe intercept file:// requests in the plugin? If it’s
> just a
> > > >> >>path
> > > >> >> >>problem, maybe we could intercept the request, fix the path,
> then
> > > >> >>respond
> > > >> >> >>with the right thing...
> > > >> >> >>
> > > >> >> >>Tony
> > > >> >> >>
> > > >> >> >>On 10/31/14, 1:19 PM, "Andrew Grieve" <ag...@chromium.org>
> > > wrote:
> > > >> >> >>
> > > >> >> >>>Unless you're having the server proxy requests to remote
> sites,
> > I
> > > >> >>don't
> > > >> >> >>>think CORS headers are necessary.
> > > >> >> >>>
> > > >> >> >>>Tony - awesome stuff! absolutely doing it right. More
> > > >> >>technical-focused
> > > >> >> >>>discussion the better :). Using cookies seems the best way to
> me
> > > >> >>since
> > > >> >> >>>that
> > > >> >> >>>covers all requests. Adding headers works only for XHRs.
> > > >> >> >>>
> > > >> >> >>>On Fri, Oct 31, 2014 at 12:12 PM, Kirk Shoop (MS OPEN TECH) <
> > > >> >> >>>Kirk.Shoop@microsoft.com> wrote:
> > > >> >> >>>
> > > >> >> >>>> Yes, the handler should be able to add CORS headers to its
> > > >> >>responses
> > > >> >> >>>>that
> > > >> >> >>>> will enable requests from any origin.
> > > >> >> >>>>
> > > >> >> >>>> For instance adding 'Access-Control-Allow-Origin: *' would
> > allow
> > > >> >>any
> > > >> >> >>>> origin to make a request from the local server.
> > > >> >> >>>>
> > > >> >>
> > > http://www.w3.org/TR/cors/#access-control-allow-origin-response-header
> > > >> >> >>>>
> > > >> >> >>>> Similarly Access-Control-Allow-Methods and
> > > >> >> >>>>Access-Control-Allow-Headers
> > > >> >> >>>> could be used to define valid requests.
> > > >> >> >>>>
> > > >> >> >>>> Kirk
> > > >> >> >>>>
> > > >> >> >>>> Developer
> > > >> >> >>>> Microsoft Open Technologies, Inc.
> > > >> >> >>>>
> > > >> >> >>>> -----Original Message-----
> > > >> >> >>>> From: Homer, Tony [mailto:tony.homer@intel.com]
> > > >> >> >>>> Sent: Friday, October 31, 2014 8:40 AM
> > > >> >> >>>> To: dev@cordova.apache.org
> > > >> >> >>>> Subject: Re: [iOS 8] WKWebView moving forward
> > > >> >> >>>>
> > > >> >> >>>> Last night I added a handler to the Local Web Server plugin
> > that
> > > >> >> >>>>returns
> > > >> >> >>>> 403 for non-localhost requests.
> > > >> >> >>>> The handler also has a prototype token system to restrict
> > > requests
> > > >> >>to
> > > >> >> >>>>the
> > > >> >> >>>> app, but I need to change the approach a bit.
> > > >> >> >>>> Currently I set a cookie and the handler just checks for the
> > > >> cookie
> > > >> >> >>>>and
> > > >> >> >>>> returns 403 if it is missing.
> > > >> >> >>>> This is susceptible to replay attacks from backgrounded
> apps -
> > > not
> > > >> >> >>>>sure
> > > >> >> >>>>if
> > > >> >> >>>> that is important or not.
> > > >> >> >>>>
> > > >> >> >>>> I¹m going to investigate adding a map to the plugin, then
> add
> > an
> > > >> >>entry
> > > >> >> >>>>for
> > > >> >> >>>> every request.
> > > >> >> >>>> The entry will be a hash of the request and a random number.
> > > >> >> >>>>
> > > >> >> >>>> I¹ll have to wire up support for overriding url loads so
> that
> > I
> > > >> can
> > > >> >> >>>>add
> > > >> >> >>>> the header with the random number to the request.
> > > >> >> >>>> Then the request handler will look the entry up in the map
> and
> > > >> >>remove
> > > >> >> >>>>it -
> > > >> >> >>>> this should eliminate re-playability.
> > > >> >> >>>>
> > > >> >> >>>> I¹m not sure about the CORS issue with camera pluginŠ I¹ll
> be
> > > >> >>curious
> > > >> >> >>>>to
> > > >> >> >>>> test it - maybe it could be addressed by modifying the
> > response
> > > in
> > > >> >>the
> > > >> >> >>>> GCDWebServer handler?
> > > >> >> >>>>
> > > >> >> >>>> Tony
> > > >> >> >>>>
> > > >> >> >>>> P.S. This is my first attempt participating in discussion on
> > the
> > > >> >>list
> > > >> >> >>>>-
> > > >> >> >>>> let me know if I¹m doing it wrong!
> > > >> >> >>>> Am I wasting my time investigating this? Should I just leave
> > it
> > > >> >> >>>>Shazron?
> > > >> >> >>>>
> > > >> >> >>>> On 10/30/14, 9:52 PM, "Andrew Grieve" <agrieve@chromium.org
> >
> > > >> wrote:
> > > >> >> >>>>
> > > >> >> >>>> >On Thu, Oct 30, 2014 at 5:05 PM, Shazron <
> shazron@gmail.com>
> > > >> >>wrote:
> > > >> >> >>>> >
> > > >> >> >>>> >> The port conflict situation has been solved with the
> latest
> > > >> >>version
> > > >> >> >>>> >>of the plugin. Passing in a port of "0" will choose a
> random
> > > >> >>port.
> > > >> >> >>>> >>More details in the plugin's README.md
> > > >> >> >>>> >>
> > > >> >> >>>> >Awesome! Why even allow a non-random port?
> > > >> >> >>>> >Also learned today that in chrome, webcrypto API is
> disabled
> > > for
> > > >> >>http
> > > >> >> >>>> >origins, but enabled for https. Not sure if this is true
> for
> > > >> >>Safari
> > > >> >> >>>>as
> > > >> >> >>>> >well, but certainly this change will be a can of worms!
> > > >> >> >>>> >
> > > >> >> >>>> >
> > > >> >> >>>> >>
> > > >> >> >>>> >> Ouch - didn't think about Camera plugin and File plugin
> > > impact.
> > > >> >> >>>>That
> > > >> >> >>>> >>proxy thing might work, as long as there are no folder
> name
> > > >> >> >>>> >>collisions.
> > > >> >> >>>> >>
> > > >> >> >>>> >Prefixing all resources into a fake top-level directory
> will
> > > >> >> >>>>eliminate
> > > >> >> >>>> >the folder name collision problem I think.
> > > >> >> >>>> >
> > > >> >> >>>> >
> > > >> >> >>>> >>
> > > >> >> >>>> >> My point regarding mixing WKWebView and UIWebView on iOS
> 8
> > > is,
> > > >> >>if
> > > >> >> >>>>you
> > > >> >> >>>> >>have a user on iOS 8.x, you want all users on that iOS
> > > version
> > > >> >>to
> > > >> >> >>>> >>have the same experience, and for bug reporting purposes.
> > > >> >> >>>> >
> > > >> >> >>>> >
> > > >> >> >>>> >> On Wed, Oct 29, 2014 at 5:11 PM, Andrew Grieve
> > > >> >> >>>><ag...@chromium.org>
> > > >> >> >>>> >> wrote:
> > > >> >> >>>> >>
> > > >> >> >>>> >> > We could restrict access to the webserver by stuffing a
> > > >> cookie
> > > >> >> >>>>into
> > > >> >> >>>> >>the
> > > >> >> >>>> >> > webview with an access token, then have the server just
> > 500
> > > >> on
> > > >> >> >>>>any
> > > >> >> >>>> >> request
> > > >> >> >>>> >> > missing the cookie. We should also be able to restrict
> > > >> >>external
> > > >> >> >>>> >>requests
> > > >> >> >>>> >> > just by listening on 127.0.0.1 instead of 0.0.0.0
> > (doesn't
> > > >> >>look
> > > >> >> >>>> >> > like GCDWebServer supports this, but we can hack it
> in).
> > > >> >> >>>> >> >
> > > >> >> >>>> >> > The problem of port conflicts is annoying though. Maybe
> > we
> > > >> try
> > > >> >> >>>>random
> > > >> >> >>>> >> ports
> > > >> >> >>>> >> > until one works? Is there any need to use the same port
> > for
> > > >> >> >>>>multiple
> > > >> >> >>>> >> runs?
> > > >> >> >>>> >> >
> > > >> >> >>>> >> > The CORS thing is sad, because it also means things
> like
> > > >> >>Camera
> > > >> >> >>>>plugin
> > > >> >> >>>> >> will
> > > >> >> >>>> >> > be broken (can't use resulting URL in <img>).
> > > >> >> >>>> >> >
> > > >> >> >>>> >> > Although we might just do (this is different than the
> > > current
> > > >> >> >>>>mapping
> > > >> >> >>>> >>in
> > > >> >> >>>> >> > the plugin):
> > > >> >> >>>> >> > http://localhost:RANDOM_PORT/www
> > > >> >> >>>> >> > http://localhost:RANDOM_PORT/asset-library
> > > >> >> >>>> >> > http://localhost:RANDOM_PORT/file-system
> > > >> >> >>>> >> >
> > > >> >> >>>> >> > to proxy the three locations.
> > > >> >> >>>> >> >
> > > >> >> >>>> >> > This also means we can't use FileEntry.toURL() and have
> > it
> > > >> >>work,
> > > >> >> >>>> >>unless
> > > >> >> >>>> >> > toURL returns http://localhost:RANDOM_PORT
> > /file-system/...
> > > >> >> >>>>Maybe
> > > >> >> >>>> >> that's
> > > >> >> >>>> >> > fine?
> > > >> >> >>>> >> >
> > > >> >> >>>> >> >
> > > >> >> >>>> >> > I don't think it's weird that an app will need to
> support
> > > >> >> >>>>WKWebView on
> > > >> >> >>>> >> some
> > > >> >> >>>> >> > OS versions, and UIWebView on others. That's already
> the
> > > case
> > > >> >>to
> > > >> >> >>>> >>support
> > > >> >> >>>> >> > iOS 7.
> > > >> >> >>>> >> >
> > > >> >> >>>> >> >
> > > >> >> >>>> >> >
> > > >> >> >>>> >> > On Wed, Oct 29, 2014 at 6:22 PM, Shazron <
> > > shazron@gmail.com>
> > > >> >> >>>>wrote:
> > > >> >> >>>> >> >
> > > >> >> >>>> >> > > This does not preclude using the file url API
> function
> > I
> > > >> >> >>>>suppose.
> > > >> >> >>>> >> Here's
> > > >> >> >>>> >> > a
> > > >> >> >>>> >> > > flowchart on how I think it would work:
> > > >> >> >>>> >>http://i.imgur.com/zq4zreN.png
> > > >> >> >>>> >> > >
> > > >> >> >>>> >> > >
> > > >> >> >>>> >> > > On Wed, Oct 29, 2014 at 2:48 PM, Tommy Williams
> > > >> >> >>>><tommy@devgeeks.org
> > > >> >> >>>> >
> > > >> >> >>>> >> > > wrote:
> > > >> >> >>>> >> > >
> > > >> >> >>>> >> > > > This whole thing reeks of sadness and pain.
> > > >> >> >>>> >> > > >
> > > >> >> >>>> >> > > > The security implications of this will have to be
> > > >> >>considered
> > > >> >> >>>>very
> > > >> >> >>>> >> > > > carefully.
> > > >> >> >>>> >> > > > On 29 Oct 2014 16:40, "Shazron" <
> shazron@apache.org>
> > > >> >>wrote:
> > > >> >> >>>> >> > > >
> > > >> >> >>>> >> > > > > ## What We Know So Far
> > > >> >> >>>> >> > > > >
> > > >> >> >>>> >> > > > > 1. Because of the file:// url loading bug, we
> > > couldn't
> > > >> >> >>>>support
> > > >> >> >>>> >>the
> > > >> >> >>>> >> > > > > WKWebView in the iOS 8 GM release. It has since
> > been
> > > >> >>fixed,
> > > >> >> >>>>for
> > > >> >> >>>> >> > release
> > > >> >> >>>> >> > > > > post iOS 8.1 (not sure when), through a new
> > WKWebView
> > > >> >>API
> > > >> >> >>>> >>function
> > > >> >> >>>> >> (
> > > >> >> >>>> >> > > > > http://trac.webkit.org/changeset/174029/trunk)
> > > >> >> >>>> >> > > > > 2. The alternative is embedding a local web
> server
> > > and
> > > >> >> >>>>serving
> > > >> >> >>>> >> assets
> > > >> >> >>>> >> > > > from
> > > >> >> >>>> >> > > > > that
> > > >> >> >>>> >> > > > >
> > > >> >> >>>> >> > > > > ## Abandon file:// url Loading API Method
> > > >> >> >>>> >> > > > >
> > > >> >> >>>> >> > > > > My proposal is, we abandon the local file:// url
> > > >> loading
> > > >> >> >>>>method
> > > >> >> >>>> >>in
> > > >> >> >>>> >> > (1)
> > > >> >> >>>> >> > > > > above, since it will create problems with
> support.
> > > >> >> >>>> >> > > > >
> > > >> >> >>>> >> > > > > For example, if we support the new local file url
> > > >> >>loading
> > > >> >> >>>>API
> > > >> >> >>>> >> > function
> > > >> >> >>>> >> > > in
> > > >> >> >>>> >> > > > > iOS 8.2.0 (speculated) -- and a user is on 8.0.2,
> > > what
> > > >> >> >>>>then?
> > > >> >> >>>>You
> > > >> >> >>>> >> > would
> > > >> >> >>>> >> > > > not
> > > >> >> >>>> >> > > > > have WKWebView support for that user, and you
> would
> > > use
> > > >> >> >>>> >>UIWebView
> > > >> >> >>>> >> > > > instead.
> > > >> >> >>>> >> > > > > This will just be confusing, and leads to
> problems.
> > > >> >> >>>> >> > > > >
> > > >> >> >>>> >> > > > > With the embedded local web server method, you
> can
> > > >> >>support
> > > >> >> >>>> >>**any**
> > > >> >> >>>> >> > > > version
> > > >> >> >>>> >> > > > > of iOS 8.x.
> > > >> >> >>>> >> > > > >
> > > >> >> >>>> >> > > > > ## Embrace Embedded Local Web Server Method
> > > >> >> >>>> >> > > > >
> > > >> >> >>>> >> > > > > I have a Cordova plugin that implements this, and
> > it
> > > >> >>should
> > > >> >> >>>>work
> > > >> >> >>>> >> with
> > > >> >> >>>> >> > > > > cordova-ios 3.7.0:
> > > >> >> >>>> >> > > > > https://github.com/shazron/CordovaLocalWebServer
> > > >> >> >>>> >> > > > >
> > > >> >> >>>> >> > > > > It dynamically updates the <access> tag value
> when
> > it
> > > >> >> >>>>loads,
> > > >> >> >>>> >> > overriding
> > > >> >> >>>> >> > > > it
> > > >> >> >>>> >> > > > > to the actual location and port. Since it is a
> > > plugin,
> > > >> >>it
> > > >> >> >>>>can be
> > > >> >> >>>> >> > > > swappable
> > > >> >> >>>> >> > > > > (for whatever reason).
> > > >> >> >>>> >> > > > >
> > > >> >> >>>> >> > > > > It does not solve the problem where any
> > backgrounded
> > > >> app
> > > >> >> >>>>can
> > > >> >> >>>> >>access
> > > >> >> >>>> >> > our
> > > >> >> >>>> >> > > > > local web server.
> > > >> >> >>>> >> > > > >
> > > >> >> >>>> >> > > > > ## Future Steps
> > > >> >> >>>> >> > > > >
> > > >> >> >>>> >> > > > > This plugin is already working in cordova-ios
> 3.7.0
> > > >> >> >>>> >>(un-released,
> > > >> >> >>>> >> up
> > > >> >> >>>> >> > > next
> > > >> >> >>>> >> > > > > for vote release).
> > > >> >> >>>> >> > > > >
> > > >> >> >>>> >> > > > > The wkwebview branch:
> > > >> >> >>>> >> > > > >
> > > >> >> >>>> >> > > > > 1. Needs be rebased
> > > >> >> >>>> >> > > > > 2. Needs to be re-tested
> > > >> >> >>>> >> > > > > 3. issues in CB-7043 that relate to the wkwebview
> > > have
> > > >> >>to
> > > >> >> >>>>be
> > > >> >> >>>> >> resolved
> > > >> >> >>>> >> > > > > 4. branch presented for review to other
> committers
> > > >> >> >>>> >> > > > > 5. resolve any comments and issues from (4)
> > > >> >> >>>> >> > > > > 6. wkwebview branch integrated into master
> > > >> >> >>>> >> > > > >
> > > >> >> >>>> >> > > > > I will work on these items next after getting
> > > >> >>cordova-ios
> > > >> >> >>>>3.7.0
> > > >> >> >>>> >> out.
> > > >> >> >>>> >> > > Any
> > > >> >> >>>> >> > > > > help is welcome.
> > > >> >> >>>> >> > > > >
> > > >> >> >>>> >> > > > > ## Migration Issues
> > > >> >> >>>> >> > > > >
> > > >> >> >>>> >> > > > > If you are migrating to WKWebView from UIWebView,
> > you
> > > >> >>will
> > > >> >> >>>>lose
> > > >> >> >>>> >> some
> > > >> >> >>>> >> > > > > functionality.
> > > >> >> >>>> >> > > > >
> > > >> >> >>>> >> > > > > 1. No more whitelist feature (NSURLProtocol is
> not
> > > >> >> >>>>supported
> > > >> >> >>>>in
> > > >> >> >>>> >> > > > WKWebView)
> > > >> >> >>>> >> > > > > 2. Your XmlHttpRequest calls now need to be CORS
> > > >> >>compliant
> > > >> >> >>>> >>(this is
> > > >> >> >>>> >> > > still
> > > >> >> >>>> >> > > > > true if loaded through a file:// url)
> > > >> >> >>>> >> > > > > 3. HTML5 offline application cache is not
> available
> > > in
> > > >> >> >>>> >>WKWebView (
> > > >> >> >>>> >> > > > > https://devforums.apple.com/message/1060452)
> > > >> >> >>>> >> > > > >
> > > >> >> >>>> >> > > >
> > > >> >> >>>> >> > >
> > > >> >> >>>> >> >
> > > >> >> >>>> >>
> > > >> >> >>>>
> > > >> >> >>>>
> > > >> >> >>>>
> > > >>
> > >>---------------------------------------------------------------------
> > > >> >> >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > >> >> >>>> For additional commands, e-mail:
> dev-help@cordova.apache.org
> > > >> >> >>>>
> > > >> >> >>>>
> > > >> >> >>>>
> > > >>
> > >>---------------------------------------------------------------------
> > > >> >> >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > >> >> >>>> For additional commands, e-mail:
> dev-help@cordova.apache.org
> > > >> >> >>>>
> > > >> >> >>>>
> > > >> >> >>
> > > >> >> >
> > > >> >>
> > > >> >>
> > > >> >>
> > ---------------------------------------------------------------------
> > > >> >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > >> >> For additional commands, e-mail: dev-help@cordova.apache.org
> > > >> >>
> > > >>
> > > >>
> > > >
> > >
> >
>
Re: [iOS 8] WKWebView moving forward
Posted by tommy-carlos williams <to...@devgeeks.org>.
Yeah… I’ll try to report some of it and get back to you.
--
tommy-carlos williams
On 11 November 2014 at 09:50:55, Shazron (shazron@gmail.com) wrote:
Bug report? Or email me personally. Which ones besides the ones that will
have problems as we discussed on this thread.
On Mon, Nov 10, 2014 at 2:41 PM, tommy-carlos williams <to...@devgeeks.org>
wrote:
> I had much less success… it doesn’t play well with other legacy plugins,
> does it?
>
>
>
> --
> tommy-carlos williams
>
> On 11 November 2014 at 03:00:30, Michal Mocny (mmocny@chromium.org) wrote:
>
> Success! I did indeed have to add the framework manually.
>
> Thanks for instructions.
>
> On Thu, Nov 6, 2014 at 7:49 PM, Shazron <sh...@gmail.com> wrote:
>
> > There have been major changes to the `wkwebview` branch of `cordova-ios`.
> > The `WKWebView` functionality has been moved to a plugin in the
> > `cordova-plugins` repo.
> >
> > So, for now you can do:
> >
> > cordova create wkwvtest test.project wkwvtest
> > cd wkwvtest
> > cordova platform add ios@wkwebview --usegit
> > cordova plugin add
> > https://github.com/apache/cordova-plugins.git#master:wkwebview-engine
> >
> > Modify the root `config.xml` and edit this value to:
> >
> > <content src="http://localhost:0" />
> >
> > Then:
> >
> > cordova emulate
> >
> > You might get a build error, this is a `plugman` bug that doesn't install
> > `WebKit.framework` properly even though it is defined in plugin.xml. You
> > might have to do a:
> >
> > open -a Xcode platforms/ios
> >
> > ...and add the framework manually.
> >
> > On Thu, Nov 6, 2014 at 11:15 AM, Shazron <sh...@gmail.com> wrote:
> >
> > > Thanks Tony - I'll look at that PR when I have some time.
> > >
> > > Yesterday I did some major work to isolate the webviews into plugins
> > > (CDVWKWebViewEngine, CDVUIWebViewEngine). This way we can reduce the
> risk
> > > by extracting the WKWebView items into a plugin, and the core has no
> > > dependency on WebKit.framework anymore, plus speedy (well, speedier)
> > > updates if it needs updating. The CDVUIWebViewEngine will remain in the
> > > core as the default engine. I'm still working on this, but it already
> > works
> > > currently. I'm abstracting things out more, and removing code from the
> > > CDVViewController which has become unwieldy.
> > >
> > > Swapping out engines would use the preference:
> > > <preference name="CordovaWebViewEngine" value="CDVWKWebViewEngine" />
> > >
> > > Any new web engine needs to implement the new CDVWebViewEngineProtocol
> > > protocol, and installed as a plugin.
> > >
> > > On Mon, Nov 3, 2014 at 6:55 PM, Homer, Tony <to...@intel.com>
> > wrote:
> > >
> > >> I have already forked it and made the changes in a topic branch.
> > >> I was originally thinking that I would make 2 topic branches: 1 for
> > >> localhost-only and 1 for auth tokens.
> > >> However, after I finished the first set of changes I realized that the
> > >> second set would be dependent on the first.
> > >> I’ll submit a pull request tomorrow for you to look at - I’ll be happy
> > to
> > >> redo it as multiple branches if that makes sense.
> > >>
> > >> I got a little sidetracked with local web server plugin, but I’ve also
> > >> forked cordova-ios and made a topic branch from wkwebview.
> > >> I'll start working on some of the changes I proposed earlier in this
> > >> thread tomorrow (for plugins like camera that return file:// urls,
> > etc.).
> > >>
> > >> Tony
> > >>
> > >> On 11/3/14, 7:23 PM, "Shazron" <sh...@gmail.com> wrote:
> > >>
> > >> >Thanks Tony for all the investigation. Please do fork the local web
> > >> server
> > >> >plugin and put all your work in topic branches for eventual pull
> > requests
> > >> >to the main repo.
> > >> >
> > >> >This is precisely why the local web server is a plugin, and not in
> the
> > >> >core. I don't profess to be a security expert, and we can update this
> > >> >plugin to cover most of the security cases or someone else can
> provide
> > >> >their better plugin. I don't think this needs to be bulletproof, not
> > that
> > >> >we can entirely be (has there ever been a Security Update by Apple
> that
> > >> >*didn't* include a WebKit vulnerability?)
> > >> >
> > >> >I'd like to get the cordova-ios/wkwebview branch back into the
> mainline
> > >> as
> > >> >soon as possible, but under an experimental flag (--experimental ?)
> > for
> > >> >bin/create. This will choose a new template that has WebKit.framework
> > in
> > >> >it, which will also define a macro to conditionally compile the new
> > bits
> > >> >in
> > >> >(I haven't added the macros yet in the topic branch).
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >On Mon, Nov 3, 2014 at 7:27 AM, Homer, Tony <to...@intel.com>
> > >> wrote:
> > >> >
> > >> >> I spent a lot of time thinking about ways to avoid replay attacks
> for
> > >> >>the
> > >> >> local web server plugin this weekend.
> > >> >>
> > >> >> Specifically, I felt like there should be a way to take advantage
> of
> > >> the
> > >> >> fact that the client and the server are running in the same
> process.
> > >> >> I thought this might enable some kind of sideband (non-http)
> > >> >> authentication possibility.
> > >> >> The 2 possibilities I was most interested in, but eventually
> > concluded
> > >> >>are
> > >> >> not practical were:
> > >> >> 1. unique token per http request - not practical because there is
> no
> > >> per
> > >> >> http request event available
> > >> >> 2. a whitelist of “remote” ports - not practical because there is
> no
> > >> >> simple way to get a list of ports in use by WKWebView
> > >> >>
> > >> >> After going down this rathole and coming up empty, I reconsidered
> the
> > >> >> original problem and came to the following conclusions.
> > >> >> 1. restricting requests to localhost-only limits “attacks” to
> > >> >>backgrounded
> > >> >> apps
> > >> >> 2. including a token in the requests will prevent backgrounded apps
> > >> from
> > >> >> being able to successfully make unwanted requests
> > >> >> 3. the token is vulnerable to network analysis, but that cannot be
> > done
> > >> >>on
> > >> >> device
> > >> >>
> > >> >> Therefore, vulnerability is limited to the case where the there is
> > >> >> (1) a “hostile" app installed on device and running in the
> background
> > >> >>and
> > >> >> (2) the user’s device is connected to a wi-fi network where an
> > attacker
> > >> >>is
> > >> >> able to perform network analysis to capture the token.
> > >> >> In this case, the attacker could just inspect the HTTP traffic
> > instead
> > >> >>of
> > >> >> capturing the token and sending it to their backgrounded app.
> > >> >> In other words, it seems that replay attacks are possible but not
> > >> >>useful.
> > >> >> If we care about the “hostile wifi network” case, we need something
> > >> like
> > >> >> SSL.
> > >> >>
> > >> >> On 11/1/14, 4:28 PM, "Homer, Tony" <to...@intel.com> wrote:
> > >> >>
> > >> >> >I started looking at how to make the camera plugin be able to work
> > in
> > >> >> >WKWebView.
> > >> >> >Before, I had mentioned intercepting resource requests as a way to
> > fix
> > >> >>the
> > >> >> >file:// requests.
> > >> >> >However, WKWebView does not offer a way to intercept resource
> > requests
> > >> >>so
> > >> >> >that won’t work.
> > >> >> >:/
> > >> >> >
> > >> >> >Andrew had suggested introducing some proxy paths as a way to deal
> > >> with
> > >> >> >the path problems, which seems fine.
> > >> >> >On the other hand, the request handlers could just inspect the
> path
> > in
> > >> >>the
> > >> >> >request and do the right thing - are the proxy paths needed?
> > >> >> >I think implicit in those comments was a suggestion that the
> > affected
> > >> >> >plugins such as camera could return URLs using those paths.
> > >> >> >The thing about changing camera and file plugins to support
> > localhost
> > >> >>that
> > >> >> >bothers me, is that now those core plugins effectively support a
> > >> >>non-core
> > >> >> >plugin.
> > >> >> >Also, other (on-cordova) plugins that depend on file protocol will
> > be
> > >> >> >incompatible with the local web server wkwebview solution (unless
> > they
> > >> >> >make changes to support it).
> > >> >> >
> > >> >> >I wonder if it would be better to handle this in CDVPluginResult?
> > >> >> >A hook could be added to initWithStatus and exposed to plugins.
> > >> >> >Then the SALocalWebServer plugin can use the hook to inspect the
> > >> >>message
> > >> >> >and fix it, if it is a file:// URL.
> > >> >> >So, for example, when camera calls CDVPluginResult
> > >> >> >resultWithStatus:messageAsString and passes in a file URL,
> > >> >>SALocalServer
> > >> >> >can get a chance to inspect and modify the result – changing it to
> > an
> > >> >> >http:localhost URL. It could simply replace the file protocol with
> > >> >> >http://localhost:port, then the handler could decode the path
> > before
> > >> >> >building the response.
> > >> >> >This is ugly, but it would prevent the need to change the camera
> and
> > >> >>file
> > >> >> >and should allow other non-cordova plugins that depend on file://
> > URLs
> > >> >>to
> > >> >> >work.
> > >> >> >
> > >> >> >
> > >> >> >Tony
> > >> >> >
> > >> >> >On 10/31/14, 2:03 PM, "Homer, Tony" <to...@intel.com> wrote:
> > >> >> >
> > >> >> >>I started with cookies in my POC, but I was concerned about
> replay
> > >> >> >>attacks.
> > >> >> >>I couldn’t think of a way to avoid replay vulnerability with
> > cookies
> > >> >> >>(without SSL), so I was going to switch to the side channel
> > approach
> > >> I
> > >> >> >>tried to describe. Do you think replay vulnerability is
> > irrelevant?
> > >> >>I’m
> > >> >> >>not a security guy, so I wasn’t sure if it mattered or not.
> That’s
> > >> >> >>actually one of the things I was hoping to get feedback about.
> > >> >> >>
> > >> >> >>I guess I don’t follow how CORS relates to the camera plugin,
> does
> > it
> > >> >>use
> > >> >> >>XHR? Maybe you can elaborate?
> > >> >> >>I expect I’ll see it when I try the camera plugin from WKWebView,
> > >> just
> > >> >> >>didn’t get around to it yet.
> > >> >> >>The only thing that jumps out at me is that you get a file:// url
> > >> >>back -
> > >> >> >>we could change that.
> > >> >> >>Or maybe intercept file:// requests in the plugin? If it’s just a
> > >> >>path
> > >> >> >>problem, maybe we could intercept the request, fix the path, then
> > >> >>respond
> > >> >> >>with the right thing...
> > >> >> >>
> > >> >> >>Tony
> > >> >> >>
> > >> >> >>On 10/31/14, 1:19 PM, "Andrew Grieve" <ag...@chromium.org>
> > wrote:
> > >> >> >>
> > >> >> >>>Unless you're having the server proxy requests to remote sites,
> I
> > >> >>don't
> > >> >> >>>think CORS headers are necessary.
> > >> >> >>>
> > >> >> >>>Tony - awesome stuff! absolutely doing it right. More
> > >> >>technical-focused
> > >> >> >>>discussion the better :). Using cookies seems the best way to me
> > >> >>since
> > >> >> >>>that
> > >> >> >>>covers all requests. Adding headers works only for XHRs.
> > >> >> >>>
> > >> >> >>>On Fri, Oct 31, 2014 at 12:12 PM, Kirk Shoop (MS OPEN TECH) <
> > >> >> >>>Kirk.Shoop@microsoft.com> wrote:
> > >> >> >>>
> > >> >> >>>> Yes, the handler should be able to add CORS headers to its
> > >> >>responses
> > >> >> >>>>that
> > >> >> >>>> will enable requests from any origin.
> > >> >> >>>>
> > >> >> >>>> For instance adding 'Access-Control-Allow-Origin: *' would
> allow
> > >> >>any
> > >> >> >>>> origin to make a request from the local server.
> > >> >> >>>>
> > >> >>
> > http://www.w3.org/TR/cors/#access-control-allow-origin-response-header
> > >> >> >>>>
> > >> >> >>>> Similarly Access-Control-Allow-Methods and
> > >> >> >>>>Access-Control-Allow-Headers
> > >> >> >>>> could be used to define valid requests.
> > >> >> >>>>
> > >> >> >>>> Kirk
> > >> >> >>>>
> > >> >> >>>> Developer
> > >> >> >>>> Microsoft Open Technologies, Inc.
> > >> >> >>>>
> > >> >> >>>> -----Original Message-----
> > >> >> >>>> From: Homer, Tony [mailto:tony.homer@intel.com]
> > >> >> >>>> Sent: Friday, October 31, 2014 8:40 AM
> > >> >> >>>> To: dev@cordova.apache.org
> > >> >> >>>> Subject: Re: [iOS 8] WKWebView moving forward
> > >> >> >>>>
> > >> >> >>>> Last night I added a handler to the Local Web Server plugin
> that
> > >> >> >>>>returns
> > >> >> >>>> 403 for non-localhost requests.
> > >> >> >>>> The handler also has a prototype token system to restrict
> > requests
> > >> >>to
> > >> >> >>>>the
> > >> >> >>>> app, but I need to change the approach a bit.
> > >> >> >>>> Currently I set a cookie and the handler just checks for the
> > >> cookie
> > >> >> >>>>and
> > >> >> >>>> returns 403 if it is missing.
> > >> >> >>>> This is susceptible to replay attacks from backgrounded apps -
> > not
> > >> >> >>>>sure
> > >> >> >>>>if
> > >> >> >>>> that is important or not.
> > >> >> >>>>
> > >> >> >>>> I¹m going to investigate adding a map to the plugin, then add
> an
> > >> >>entry
> > >> >> >>>>for
> > >> >> >>>> every request.
> > >> >> >>>> The entry will be a hash of the request and a random number.
> > >> >> >>>>
> > >> >> >>>> I¹ll have to wire up support for overriding url loads so that
> I
> > >> can
> > >> >> >>>>add
> > >> >> >>>> the header with the random number to the request.
> > >> >> >>>> Then the request handler will look the entry up in the map and
> > >> >>remove
> > >> >> >>>>it -
> > >> >> >>>> this should eliminate re-playability.
> > >> >> >>>>
> > >> >> >>>> I¹m not sure about the CORS issue with camera pluginŠ I¹ll be
> > >> >>curious
> > >> >> >>>>to
> > >> >> >>>> test it - maybe it could be addressed by modifying the
> response
> > in
> > >> >>the
> > >> >> >>>> GCDWebServer handler?
> > >> >> >>>>
> > >> >> >>>> Tony
> > >> >> >>>>
> > >> >> >>>> P.S. This is my first attempt participating in discussion on
> the
> > >> >>list
> > >> >> >>>>-
> > >> >> >>>> let me know if I¹m doing it wrong!
> > >> >> >>>> Am I wasting my time investigating this? Should I just leave
> it
> > >> >> >>>>Shazron?
> > >> >> >>>>
> > >> >> >>>> On 10/30/14, 9:52 PM, "Andrew Grieve" <ag...@chromium.org>
> > >> wrote:
> > >> >> >>>>
> > >> >> >>>> >On Thu, Oct 30, 2014 at 5:05 PM, Shazron <sh...@gmail.com>
> > >> >>wrote:
> > >> >> >>>> >
> > >> >> >>>> >> The port conflict situation has been solved with the latest
> > >> >>version
> > >> >> >>>> >>of the plugin. Passing in a port of "0" will choose a random
> > >> >>port.
> > >> >> >>>> >>More details in the plugin's README.md
> > >> >> >>>> >>
> > >> >> >>>> >Awesome! Why even allow a non-random port?
> > >> >> >>>> >Also learned today that in chrome, webcrypto API is disabled
> > for
> > >> >>http
> > >> >> >>>> >origins, but enabled for https. Not sure if this is true for
> > >> >>Safari
> > >> >> >>>>as
> > >> >> >>>> >well, but certainly this change will be a can of worms!
> > >> >> >>>> >
> > >> >> >>>> >
> > >> >> >>>> >>
> > >> >> >>>> >> Ouch - didn't think about Camera plugin and File plugin
> > impact.
> > >> >> >>>>That
> > >> >> >>>> >>proxy thing might work, as long as there are no folder name
> > >> >> >>>> >>collisions.
> > >> >> >>>> >>
> > >> >> >>>> >Prefixing all resources into a fake top-level directory will
> > >> >> >>>>eliminate
> > >> >> >>>> >the folder name collision problem I think.
> > >> >> >>>> >
> > >> >> >>>> >
> > >> >> >>>> >>
> > >> >> >>>> >> My point regarding mixing WKWebView and UIWebView on iOS 8
> > is,
> > >> >>if
> > >> >> >>>>you
> > >> >> >>>> >>have a user on iOS 8.x, you want all users on that iOS
> > version
> > >> >>to
> > >> >> >>>> >>have the same experience, and for bug reporting purposes.
> > >> >> >>>> >
> > >> >> >>>> >
> > >> >> >>>> >> On Wed, Oct 29, 2014 at 5:11 PM, Andrew Grieve
> > >> >> >>>><ag...@chromium.org>
> > >> >> >>>> >> wrote:
> > >> >> >>>> >>
> > >> >> >>>> >> > We could restrict access to the webserver by stuffing a
> > >> cookie
> > >> >> >>>>into
> > >> >> >>>> >>the
> > >> >> >>>> >> > webview with an access token, then have the server just
> 500
> > >> on
> > >> >> >>>>any
> > >> >> >>>> >> request
> > >> >> >>>> >> > missing the cookie. We should also be able to restrict
> > >> >>external
> > >> >> >>>> >>requests
> > >> >> >>>> >> > just by listening on 127.0.0.1 instead of 0.0.0.0
> (doesn't
> > >> >>look
> > >> >> >>>> >> > like GCDWebServer supports this, but we can hack it in).
> > >> >> >>>> >> >
> > >> >> >>>> >> > The problem of port conflicts is annoying though. Maybe
> we
> > >> try
> > >> >> >>>>random
> > >> >> >>>> >> ports
> > >> >> >>>> >> > until one works? Is there any need to use the same port
> for
> > >> >> >>>>multiple
> > >> >> >>>> >> runs?
> > >> >> >>>> >> >
> > >> >> >>>> >> > The CORS thing is sad, because it also means things like
> > >> >>Camera
> > >> >> >>>>plugin
> > >> >> >>>> >> will
> > >> >> >>>> >> > be broken (can't use resulting URL in <img>).
> > >> >> >>>> >> >
> > >> >> >>>> >> > Although we might just do (this is different than the
> > current
> > >> >> >>>>mapping
> > >> >> >>>> >>in
> > >> >> >>>> >> > the plugin):
> > >> >> >>>> >> > http://localhost:RANDOM_PORT/www
> > >> >> >>>> >> > http://localhost:RANDOM_PORT/asset-library
> > >> >> >>>> >> > http://localhost:RANDOM_PORT/file-system
> > >> >> >>>> >> >
> > >> >> >>>> >> > to proxy the three locations.
> > >> >> >>>> >> >
> > >> >> >>>> >> > This also means we can't use FileEntry.toURL() and have
> it
> > >> >>work,
> > >> >> >>>> >>unless
> > >> >> >>>> >> > toURL returns http://localhost:RANDOM_PORT
> /file-system/...
> > >> >> >>>>Maybe
> > >> >> >>>> >> that's
> > >> >> >>>> >> > fine?
> > >> >> >>>> >> >
> > >> >> >>>> >> >
> > >> >> >>>> >> > I don't think it's weird that an app will need to support
> > >> >> >>>>WKWebView on
> > >> >> >>>> >> some
> > >> >> >>>> >> > OS versions, and UIWebView on others. That's already the
> > case
> > >> >>to
> > >> >> >>>> >>support
> > >> >> >>>> >> > iOS 7.
> > >> >> >>>> >> >
> > >> >> >>>> >> >
> > >> >> >>>> >> >
> > >> >> >>>> >> > On Wed, Oct 29, 2014 at 6:22 PM, Shazron <
> > shazron@gmail.com>
> > >> >> >>>>wrote:
> > >> >> >>>> >> >
> > >> >> >>>> >> > > This does not preclude using the file url API function
> I
> > >> >> >>>>suppose.
> > >> >> >>>> >> Here's
> > >> >> >>>> >> > a
> > >> >> >>>> >> > > flowchart on how I think it would work:
> > >> >> >>>> >>http://i.imgur.com/zq4zreN.png
> > >> >> >>>> >> > >
> > >> >> >>>> >> > >
> > >> >> >>>> >> > > On Wed, Oct 29, 2014 at 2:48 PM, Tommy Williams
> > >> >> >>>><tommy@devgeeks.org
> > >> >> >>>> >
> > >> >> >>>> >> > > wrote:
> > >> >> >>>> >> > >
> > >> >> >>>> >> > > > This whole thing reeks of sadness and pain.
> > >> >> >>>> >> > > >
> > >> >> >>>> >> > > > The security implications of this will have to be
> > >> >>considered
> > >> >> >>>>very
> > >> >> >>>> >> > > > carefully.
> > >> >> >>>> >> > > > On 29 Oct 2014 16:40, "Shazron" <sh...@apache.org>
> > >> >>wrote:
> > >> >> >>>> >> > > >
> > >> >> >>>> >> > > > > ## What We Know So Far
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > 1. Because of the file:// url loading bug, we
> > couldn't
> > >> >> >>>>support
> > >> >> >>>> >>the
> > >> >> >>>> >> > > > > WKWebView in the iOS 8 GM release. It has since
> been
> > >> >>fixed,
> > >> >> >>>>for
> > >> >> >>>> >> > release
> > >> >> >>>> >> > > > > post iOS 8.1 (not sure when), through a new
> WKWebView
> > >> >>API
> > >> >> >>>> >>function
> > >> >> >>>> >> (
> > >> >> >>>> >> > > > > http://trac.webkit.org/changeset/174029/trunk)
> > >> >> >>>> >> > > > > 2. The alternative is embedding a local web server
> > and
> > >> >> >>>>serving
> > >> >> >>>> >> assets
> > >> >> >>>> >> > > > from
> > >> >> >>>> >> > > > > that
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > ## Abandon file:// url Loading API Method
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > My proposal is, we abandon the local file:// url
> > >> loading
> > >> >> >>>>method
> > >> >> >>>> >>in
> > >> >> >>>> >> > (1)
> > >> >> >>>> >> > > > > above, since it will create problems with support.
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > For example, if we support the new local file url
> > >> >>loading
> > >> >> >>>>API
> > >> >> >>>> >> > function
> > >> >> >>>> >> > > in
> > >> >> >>>> >> > > > > iOS 8.2.0 (speculated) -- and a user is on 8.0.2,
> > what
> > >> >> >>>>then?
> > >> >> >>>>You
> > >> >> >>>> >> > would
> > >> >> >>>> >> > > > not
> > >> >> >>>> >> > > > > have WKWebView support for that user, and you would
> > use
> > >> >> >>>> >>UIWebView
> > >> >> >>>> >> > > > instead.
> > >> >> >>>> >> > > > > This will just be confusing, and leads to problems.
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > With the embedded local web server method, you can
> > >> >>support
> > >> >> >>>> >>**any**
> > >> >> >>>> >> > > > version
> > >> >> >>>> >> > > > > of iOS 8.x.
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > ## Embrace Embedded Local Web Server Method
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > I have a Cordova plugin that implements this, and
> it
> > >> >>should
> > >> >> >>>>work
> > >> >> >>>> >> with
> > >> >> >>>> >> > > > > cordova-ios 3.7.0:
> > >> >> >>>> >> > > > > https://github.com/shazron/CordovaLocalWebServer
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > It dynamically updates the <access> tag value when
> it
> > >> >> >>>>loads,
> > >> >> >>>> >> > overriding
> > >> >> >>>> >> > > > it
> > >> >> >>>> >> > > > > to the actual location and port. Since it is a
> > plugin,
> > >> >>it
> > >> >> >>>>can be
> > >> >> >>>> >> > > > swappable
> > >> >> >>>> >> > > > > (for whatever reason).
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > It does not solve the problem where any
> backgrounded
> > >> app
> > >> >> >>>>can
> > >> >> >>>> >>access
> > >> >> >>>> >> > our
> > >> >> >>>> >> > > > > local web server.
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > ## Future Steps
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > This plugin is already working in cordova-ios 3.7.0
> > >> >> >>>> >>(un-released,
> > >> >> >>>> >> up
> > >> >> >>>> >> > > next
> > >> >> >>>> >> > > > > for vote release).
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > The wkwebview branch:
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > 1. Needs be rebased
> > >> >> >>>> >> > > > > 2. Needs to be re-tested
> > >> >> >>>> >> > > > > 3. issues in CB-7043 that relate to the wkwebview
> > have
> > >> >>to
> > >> >> >>>>be
> > >> >> >>>> >> resolved
> > >> >> >>>> >> > > > > 4. branch presented for review to other committers
> > >> >> >>>> >> > > > > 5. resolve any comments and issues from (4)
> > >> >> >>>> >> > > > > 6. wkwebview branch integrated into master
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > I will work on these items next after getting
> > >> >>cordova-ios
> > >> >> >>>>3.7.0
> > >> >> >>>> >> out.
> > >> >> >>>> >> > > Any
> > >> >> >>>> >> > > > > help is welcome.
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > ## Migration Issues
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > If you are migrating to WKWebView from UIWebView,
> you
> > >> >>will
> > >> >> >>>>lose
> > >> >> >>>> >> some
> > >> >> >>>> >> > > > > functionality.
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > 1. No more whitelist feature (NSURLProtocol is not
> > >> >> >>>>supported
> > >> >> >>>>in
> > >> >> >>>> >> > > > WKWebView)
> > >> >> >>>> >> > > > > 2. Your XmlHttpRequest calls now need to be CORS
> > >> >>compliant
> > >> >> >>>> >>(this is
> > >> >> >>>> >> > > still
> > >> >> >>>> >> > > > > true if loaded through a file:// url)
> > >> >> >>>> >> > > > > 3. HTML5 offline application cache is not available
> > in
> > >> >> >>>> >>WKWebView (
> > >> >> >>>> >> > > > > https://devforums.apple.com/message/1060452)
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > >
> > >> >> >>>> >> > >
> > >> >> >>>> >> >
> > >> >> >>>> >>
> > >> >> >>>>
> > >> >> >>>>
> > >> >> >>>>
> > >>
> >>---------------------------------------------------------------------
> > >> >> >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> >> >>>> For additional commands, e-mail: dev-help@cordova.apache.org
> > >> >> >>>>
> > >> >> >>>>
> > >> >> >>>>
> > >>
> >>---------------------------------------------------------------------
> > >> >> >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> >> >>>> For additional commands, e-mail: dev-help@cordova.apache.org
> > >> >> >>>>
> > >> >> >>>>
> > >> >> >>
> > >> >> >
> > >> >>
> > >> >>
> > >> >>
> ---------------------------------------------------------------------
> > >> >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> >> For additional commands, e-mail: dev-help@cordova.apache.org
> > >> >>
> > >>
> > >>
> > >
> >
>
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
Bug report? Or email me personally. Which ones besides the ones that will
have problems as we discussed on this thread.
On Mon, Nov 10, 2014 at 2:41 PM, tommy-carlos williams <to...@devgeeks.org>
wrote:
> I had much less success… it doesn’t play well with other legacy plugins,
> does it?
>
>
>
> --
> tommy-carlos williams
>
> On 11 November 2014 at 03:00:30, Michal Mocny (mmocny@chromium.org) wrote:
>
> Success! I did indeed have to add the framework manually.
>
> Thanks for instructions.
>
> On Thu, Nov 6, 2014 at 7:49 PM, Shazron <sh...@gmail.com> wrote:
>
> > There have been major changes to the `wkwebview` branch of `cordova-ios`.
> > The `WKWebView` functionality has been moved to a plugin in the
> > `cordova-plugins` repo.
> >
> > So, for now you can do:
> >
> > cordova create wkwvtest test.project wkwvtest
> > cd wkwvtest
> > cordova platform add ios@wkwebview --usegit
> > cordova plugin add
> > https://github.com/apache/cordova-plugins.git#master:wkwebview-engine
> >
> > Modify the root `config.xml` and edit this value to:
> >
> > <content src="http://localhost:0" />
> >
> > Then:
> >
> > cordova emulate
> >
> > You might get a build error, this is a `plugman` bug that doesn't install
> > `WebKit.framework` properly even though it is defined in plugin.xml. You
> > might have to do a:
> >
> > open -a Xcode platforms/ios
> >
> > ...and add the framework manually.
> >
> > On Thu, Nov 6, 2014 at 11:15 AM, Shazron <sh...@gmail.com> wrote:
> >
> > > Thanks Tony - I'll look at that PR when I have some time.
> > >
> > > Yesterday I did some major work to isolate the webviews into plugins
> > > (CDVWKWebViewEngine, CDVUIWebViewEngine). This way we can reduce the
> risk
> > > by extracting the WKWebView items into a plugin, and the core has no
> > > dependency on WebKit.framework anymore, plus speedy (well, speedier)
> > > updates if it needs updating. The CDVUIWebViewEngine will remain in the
> > > core as the default engine. I'm still working on this, but it already
> > works
> > > currently. I'm abstracting things out more, and removing code from the
> > > CDVViewController which has become unwieldy.
> > >
> > > Swapping out engines would use the preference:
> > > <preference name="CordovaWebViewEngine" value="CDVWKWebViewEngine" />
> > >
> > > Any new web engine needs to implement the new CDVWebViewEngineProtocol
> > > protocol, and installed as a plugin.
> > >
> > > On Mon, Nov 3, 2014 at 6:55 PM, Homer, Tony <to...@intel.com>
> > wrote:
> > >
> > >> I have already forked it and made the changes in a topic branch.
> > >> I was originally thinking that I would make 2 topic branches: 1 for
> > >> localhost-only and 1 for auth tokens.
> > >> However, after I finished the first set of changes I realized that the
> > >> second set would be dependent on the first.
> > >> I’ll submit a pull request tomorrow for you to look at - I’ll be happy
> > to
> > >> redo it as multiple branches if that makes sense.
> > >>
> > >> I got a little sidetracked with local web server plugin, but I’ve also
> > >> forked cordova-ios and made a topic branch from wkwebview.
> > >> I'll start working on some of the changes I proposed earlier in this
> > >> thread tomorrow (for plugins like camera that return file:// urls,
> > etc.).
> > >>
> > >> Tony
> > >>
> > >> On 11/3/14, 7:23 PM, "Shazron" <sh...@gmail.com> wrote:
> > >>
> > >> >Thanks Tony for all the investigation. Please do fork the local web
> > >> server
> > >> >plugin and put all your work in topic branches for eventual pull
> > requests
> > >> >to the main repo.
> > >> >
> > >> >This is precisely why the local web server is a plugin, and not in
> the
> > >> >core. I don't profess to be a security expert, and we can update this
> > >> >plugin to cover most of the security cases or someone else can
> provide
> > >> >their better plugin. I don't think this needs to be bulletproof, not
> > that
> > >> >we can entirely be (has there ever been a Security Update by Apple
> that
> > >> >*didn't* include a WebKit vulnerability?)
> > >> >
> > >> >I'd like to get the cordova-ios/wkwebview branch back into the
> mainline
> > >> as
> > >> >soon as possible, but under an experimental flag (--experimental ?)
> > for
> > >> >bin/create. This will choose a new template that has WebKit.framework
> > in
> > >> >it, which will also define a macro to conditionally compile the new
> > bits
> > >> >in
> > >> >(I haven't added the macros yet in the topic branch).
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >On Mon, Nov 3, 2014 at 7:27 AM, Homer, Tony <to...@intel.com>
> > >> wrote:
> > >> >
> > >> >> I spent a lot of time thinking about ways to avoid replay attacks
> for
> > >> >>the
> > >> >> local web server plugin this weekend.
> > >> >>
> > >> >> Specifically, I felt like there should be a way to take advantage
> of
> > >> the
> > >> >> fact that the client and the server are running in the same
> process.
> > >> >> I thought this might enable some kind of sideband (non-http)
> > >> >> authentication possibility.
> > >> >> The 2 possibilities I was most interested in, but eventually
> > concluded
> > >> >>are
> > >> >> not practical were:
> > >> >> 1. unique token per http request - not practical because there is
> no
> > >> per
> > >> >> http request event available
> > >> >> 2. a whitelist of “remote” ports - not practical because there is
> no
> > >> >> simple way to get a list of ports in use by WKWebView
> > >> >>
> > >> >> After going down this rathole and coming up empty, I reconsidered
> the
> > >> >> original problem and came to the following conclusions.
> > >> >> 1. restricting requests to localhost-only limits “attacks” to
> > >> >>backgrounded
> > >> >> apps
> > >> >> 2. including a token in the requests will prevent backgrounded apps
> > >> from
> > >> >> being able to successfully make unwanted requests
> > >> >> 3. the token is vulnerable to network analysis, but that cannot be
> > done
> > >> >>on
> > >> >> device
> > >> >>
> > >> >> Therefore, vulnerability is limited to the case where the there is
> > >> >> (1) a “hostile" app installed on device and running in the
> background
> > >> >>and
> > >> >> (2) the user’s device is connected to a wi-fi network where an
> > attacker
> > >> >>is
> > >> >> able to perform network analysis to capture the token.
> > >> >> In this case, the attacker could just inspect the HTTP traffic
> > instead
> > >> >>of
> > >> >> capturing the token and sending it to their backgrounded app.
> > >> >> In other words, it seems that replay attacks are possible but not
> > >> >>useful.
> > >> >> If we care about the “hostile wifi network” case, we need something
> > >> like
> > >> >> SSL.
> > >> >>
> > >> >> On 11/1/14, 4:28 PM, "Homer, Tony" <to...@intel.com> wrote:
> > >> >>
> > >> >> >I started looking at how to make the camera plugin be able to work
> > in
> > >> >> >WKWebView.
> > >> >> >Before, I had mentioned intercepting resource requests as a way to
> > fix
> > >> >>the
> > >> >> >file:// requests.
> > >> >> >However, WKWebView does not offer a way to intercept resource
> > requests
> > >> >>so
> > >> >> >that won’t work.
> > >> >> >:/
> > >> >> >
> > >> >> >Andrew had suggested introducing some proxy paths as a way to deal
> > >> with
> > >> >> >the path problems, which seems fine.
> > >> >> >On the other hand, the request handlers could just inspect the
> path
> > in
> > >> >>the
> > >> >> >request and do the right thing - are the proxy paths needed?
> > >> >> >I think implicit in those comments was a suggestion that the
> > affected
> > >> >> >plugins such as camera could return URLs using those paths.
> > >> >> >The thing about changing camera and file plugins to support
> > localhost
> > >> >>that
> > >> >> >bothers me, is that now those core plugins effectively support a
> > >> >>non-core
> > >> >> >plugin.
> > >> >> >Also, other (on-cordova) plugins that depend on file protocol will
> > be
> > >> >> >incompatible with the local web server wkwebview solution (unless
> > they
> > >> >> >make changes to support it).
> > >> >> >
> > >> >> >I wonder if it would be better to handle this in CDVPluginResult?
> > >> >> >A hook could be added to initWithStatus and exposed to plugins.
> > >> >> >Then the SALocalWebServer plugin can use the hook to inspect the
> > >> >>message
> > >> >> >and fix it, if it is a file:// URL.
> > >> >> >So, for example, when camera calls CDVPluginResult
> > >> >> >resultWithStatus:messageAsString and passes in a file URL,
> > >> >>SALocalServer
> > >> >> >can get a chance to inspect and modify the result – changing it to
> > an
> > >> >> >http:localhost URL. It could simply replace the file protocol with
> > >> >> >http://localhost:port, then the handler could decode the path
> > before
> > >> >> >building the response.
> > >> >> >This is ugly, but it would prevent the need to change the camera
> and
> > >> >>file
> > >> >> >and should allow other non-cordova plugins that depend on file://
> > URLs
> > >> >>to
> > >> >> >work.
> > >> >> >
> > >> >> >
> > >> >> >Tony
> > >> >> >
> > >> >> >On 10/31/14, 2:03 PM, "Homer, Tony" <to...@intel.com> wrote:
> > >> >> >
> > >> >> >>I started with cookies in my POC, but I was concerned about
> replay
> > >> >> >>attacks.
> > >> >> >>I couldn’t think of a way to avoid replay vulnerability with
> > cookies
> > >> >> >>(without SSL), so I was going to switch to the side channel
> > approach
> > >> I
> > >> >> >>tried to describe. Do you think replay vulnerability is
> > irrelevant?
> > >> >>I’m
> > >> >> >>not a security guy, so I wasn’t sure if it mattered or not.
> That’s
> > >> >> >>actually one of the things I was hoping to get feedback about.
> > >> >> >>
> > >> >> >>I guess I don’t follow how CORS relates to the camera plugin,
> does
> > it
> > >> >>use
> > >> >> >>XHR? Maybe you can elaborate?
> > >> >> >>I expect I’ll see it when I try the camera plugin from WKWebView,
> > >> just
> > >> >> >>didn’t get around to it yet.
> > >> >> >>The only thing that jumps out at me is that you get a file:// url
> > >> >>back -
> > >> >> >>we could change that.
> > >> >> >>Or maybe intercept file:// requests in the plugin? If it’s just a
> > >> >>path
> > >> >> >>problem, maybe we could intercept the request, fix the path, then
> > >> >>respond
> > >> >> >>with the right thing...
> > >> >> >>
> > >> >> >>Tony
> > >> >> >>
> > >> >> >>On 10/31/14, 1:19 PM, "Andrew Grieve" <ag...@chromium.org>
> > wrote:
> > >> >> >>
> > >> >> >>>Unless you're having the server proxy requests to remote sites,
> I
> > >> >>don't
> > >> >> >>>think CORS headers are necessary.
> > >> >> >>>
> > >> >> >>>Tony - awesome stuff! absolutely doing it right. More
> > >> >>technical-focused
> > >> >> >>>discussion the better :). Using cookies seems the best way to me
> > >> >>since
> > >> >> >>>that
> > >> >> >>>covers all requests. Adding headers works only for XHRs.
> > >> >> >>>
> > >> >> >>>On Fri, Oct 31, 2014 at 12:12 PM, Kirk Shoop (MS OPEN TECH) <
> > >> >> >>>Kirk.Shoop@microsoft.com> wrote:
> > >> >> >>>
> > >> >> >>>> Yes, the handler should be able to add CORS headers to its
> > >> >>responses
> > >> >> >>>>that
> > >> >> >>>> will enable requests from any origin.
> > >> >> >>>>
> > >> >> >>>> For instance adding 'Access-Control-Allow-Origin: *' would
> allow
> > >> >>any
> > >> >> >>>> origin to make a request from the local server.
> > >> >> >>>>
> > >> >>
> > http://www.w3.org/TR/cors/#access-control-allow-origin-response-header
> > >> >> >>>>
> > >> >> >>>> Similarly Access-Control-Allow-Methods and
> > >> >> >>>>Access-Control-Allow-Headers
> > >> >> >>>> could be used to define valid requests.
> > >> >> >>>>
> > >> >> >>>> Kirk
> > >> >> >>>>
> > >> >> >>>> Developer
> > >> >> >>>> Microsoft Open Technologies, Inc.
> > >> >> >>>>
> > >> >> >>>> -----Original Message-----
> > >> >> >>>> From: Homer, Tony [mailto:tony.homer@intel.com]
> > >> >> >>>> Sent: Friday, October 31, 2014 8:40 AM
> > >> >> >>>> To: dev@cordova.apache.org
> > >> >> >>>> Subject: Re: [iOS 8] WKWebView moving forward
> > >> >> >>>>
> > >> >> >>>> Last night I added a handler to the Local Web Server plugin
> that
> > >> >> >>>>returns
> > >> >> >>>> 403 for non-localhost requests.
> > >> >> >>>> The handler also has a prototype token system to restrict
> > requests
> > >> >>to
> > >> >> >>>>the
> > >> >> >>>> app, but I need to change the approach a bit.
> > >> >> >>>> Currently I set a cookie and the handler just checks for the
> > >> cookie
> > >> >> >>>>and
> > >> >> >>>> returns 403 if it is missing.
> > >> >> >>>> This is susceptible to replay attacks from backgrounded apps -
> > not
> > >> >> >>>>sure
> > >> >> >>>>if
> > >> >> >>>> that is important or not.
> > >> >> >>>>
> > >> >> >>>> I¹m going to investigate adding a map to the plugin, then add
> an
> > >> >>entry
> > >> >> >>>>for
> > >> >> >>>> every request.
> > >> >> >>>> The entry will be a hash of the request and a random number.
> > >> >> >>>>
> > >> >> >>>> I¹ll have to wire up support for overriding url loads so that
> I
> > >> can
> > >> >> >>>>add
> > >> >> >>>> the header with the random number to the request.
> > >> >> >>>> Then the request handler will look the entry up in the map and
> > >> >>remove
> > >> >> >>>>it -
> > >> >> >>>> this should eliminate re-playability.
> > >> >> >>>>
> > >> >> >>>> I¹m not sure about the CORS issue with camera pluginŠ I¹ll be
> > >> >>curious
> > >> >> >>>>to
> > >> >> >>>> test it - maybe it could be addressed by modifying the
> response
> > in
> > >> >>the
> > >> >> >>>> GCDWebServer handler?
> > >> >> >>>>
> > >> >> >>>> Tony
> > >> >> >>>>
> > >> >> >>>> P.S. This is my first attempt participating in discussion on
> the
> > >> >>list
> > >> >> >>>>-
> > >> >> >>>> let me know if I¹m doing it wrong!
> > >> >> >>>> Am I wasting my time investigating this? Should I just leave
> it
> > >> >> >>>>Shazron?
> > >> >> >>>>
> > >> >> >>>> On 10/30/14, 9:52 PM, "Andrew Grieve" <ag...@chromium.org>
> > >> wrote:
> > >> >> >>>>
> > >> >> >>>> >On Thu, Oct 30, 2014 at 5:05 PM, Shazron <sh...@gmail.com>
> > >> >>wrote:
> > >> >> >>>> >
> > >> >> >>>> >> The port conflict situation has been solved with the latest
> > >> >>version
> > >> >> >>>> >>of the plugin. Passing in a port of "0" will choose a random
> > >> >>port.
> > >> >> >>>> >>More details in the plugin's README.md
> > >> >> >>>> >>
> > >> >> >>>> >Awesome! Why even allow a non-random port?
> > >> >> >>>> >Also learned today that in chrome, webcrypto API is disabled
> > for
> > >> >>http
> > >> >> >>>> >origins, but enabled for https. Not sure if this is true for
> > >> >>Safari
> > >> >> >>>>as
> > >> >> >>>> >well, but certainly this change will be a can of worms!
> > >> >> >>>> >
> > >> >> >>>> >
> > >> >> >>>> >>
> > >> >> >>>> >> Ouch - didn't think about Camera plugin and File plugin
> > impact.
> > >> >> >>>>That
> > >> >> >>>> >>proxy thing might work, as long as there are no folder name
> > >> >> >>>> >>collisions.
> > >> >> >>>> >>
> > >> >> >>>> >Prefixing all resources into a fake top-level directory will
> > >> >> >>>>eliminate
> > >> >> >>>> >the folder name collision problem I think.
> > >> >> >>>> >
> > >> >> >>>> >
> > >> >> >>>> >>
> > >> >> >>>> >> My point regarding mixing WKWebView and UIWebView on iOS 8
> > is,
> > >> >>if
> > >> >> >>>>you
> > >> >> >>>> >>have a user on iOS 8.x, you want all users on that iOS
> > version
> > >> >>to
> > >> >> >>>> >>have the same experience, and for bug reporting purposes.
> > >> >> >>>> >
> > >> >> >>>> >
> > >> >> >>>> >> On Wed, Oct 29, 2014 at 5:11 PM, Andrew Grieve
> > >> >> >>>><ag...@chromium.org>
> > >> >> >>>> >> wrote:
> > >> >> >>>> >>
> > >> >> >>>> >> > We could restrict access to the webserver by stuffing a
> > >> cookie
> > >> >> >>>>into
> > >> >> >>>> >>the
> > >> >> >>>> >> > webview with an access token, then have the server just
> 500
> > >> on
> > >> >> >>>>any
> > >> >> >>>> >> request
> > >> >> >>>> >> > missing the cookie. We should also be able to restrict
> > >> >>external
> > >> >> >>>> >>requests
> > >> >> >>>> >> > just by listening on 127.0.0.1 instead of 0.0.0.0
> (doesn't
> > >> >>look
> > >> >> >>>> >> > like GCDWebServer supports this, but we can hack it in).
> > >> >> >>>> >> >
> > >> >> >>>> >> > The problem of port conflicts is annoying though. Maybe
> we
> > >> try
> > >> >> >>>>random
> > >> >> >>>> >> ports
> > >> >> >>>> >> > until one works? Is there any need to use the same port
> for
> > >> >> >>>>multiple
> > >> >> >>>> >> runs?
> > >> >> >>>> >> >
> > >> >> >>>> >> > The CORS thing is sad, because it also means things like
> > >> >>Camera
> > >> >> >>>>plugin
> > >> >> >>>> >> will
> > >> >> >>>> >> > be broken (can't use resulting URL in <img>).
> > >> >> >>>> >> >
> > >> >> >>>> >> > Although we might just do (this is different than the
> > current
> > >> >> >>>>mapping
> > >> >> >>>> >>in
> > >> >> >>>> >> > the plugin):
> > >> >> >>>> >> > http://localhost:RANDOM_PORT/www
> > >> >> >>>> >> > http://localhost:RANDOM_PORT/asset-library
> > >> >> >>>> >> > http://localhost:RANDOM_PORT/file-system
> > >> >> >>>> >> >
> > >> >> >>>> >> > to proxy the three locations.
> > >> >> >>>> >> >
> > >> >> >>>> >> > This also means we can't use FileEntry.toURL() and have
> it
> > >> >>work,
> > >> >> >>>> >>unless
> > >> >> >>>> >> > toURL returns http://localhost:RANDOM_PORT
> /file-system/...
> > >> >> >>>>Maybe
> > >> >> >>>> >> that's
> > >> >> >>>> >> > fine?
> > >> >> >>>> >> >
> > >> >> >>>> >> >
> > >> >> >>>> >> > I don't think it's weird that an app will need to support
> > >> >> >>>>WKWebView on
> > >> >> >>>> >> some
> > >> >> >>>> >> > OS versions, and UIWebView on others. That's already the
> > case
> > >> >>to
> > >> >> >>>> >>support
> > >> >> >>>> >> > iOS 7.
> > >> >> >>>> >> >
> > >> >> >>>> >> >
> > >> >> >>>> >> >
> > >> >> >>>> >> > On Wed, Oct 29, 2014 at 6:22 PM, Shazron <
> > shazron@gmail.com>
> > >> >> >>>>wrote:
> > >> >> >>>> >> >
> > >> >> >>>> >> > > This does not preclude using the file url API function
> I
> > >> >> >>>>suppose.
> > >> >> >>>> >> Here's
> > >> >> >>>> >> > a
> > >> >> >>>> >> > > flowchart on how I think it would work:
> > >> >> >>>> >>http://i.imgur.com/zq4zreN.png
> > >> >> >>>> >> > >
> > >> >> >>>> >> > >
> > >> >> >>>> >> > > On Wed, Oct 29, 2014 at 2:48 PM, Tommy Williams
> > >> >> >>>><tommy@devgeeks.org
> > >> >> >>>> >
> > >> >> >>>> >> > > wrote:
> > >> >> >>>> >> > >
> > >> >> >>>> >> > > > This whole thing reeks of sadness and pain.
> > >> >> >>>> >> > > >
> > >> >> >>>> >> > > > The security implications of this will have to be
> > >> >>considered
> > >> >> >>>>very
> > >> >> >>>> >> > > > carefully.
> > >> >> >>>> >> > > > On 29 Oct 2014 16:40, "Shazron" <sh...@apache.org>
> > >> >>wrote:
> > >> >> >>>> >> > > >
> > >> >> >>>> >> > > > > ## What We Know So Far
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > 1. Because of the file:// url loading bug, we
> > couldn't
> > >> >> >>>>support
> > >> >> >>>> >>the
> > >> >> >>>> >> > > > > WKWebView in the iOS 8 GM release. It has since
> been
> > >> >>fixed,
> > >> >> >>>>for
> > >> >> >>>> >> > release
> > >> >> >>>> >> > > > > post iOS 8.1 (not sure when), through a new
> WKWebView
> > >> >>API
> > >> >> >>>> >>function
> > >> >> >>>> >> (
> > >> >> >>>> >> > > > > http://trac.webkit.org/changeset/174029/trunk)
> > >> >> >>>> >> > > > > 2. The alternative is embedding a local web server
> > and
> > >> >> >>>>serving
> > >> >> >>>> >> assets
> > >> >> >>>> >> > > > from
> > >> >> >>>> >> > > > > that
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > ## Abandon file:// url Loading API Method
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > My proposal is, we abandon the local file:// url
> > >> loading
> > >> >> >>>>method
> > >> >> >>>> >>in
> > >> >> >>>> >> > (1)
> > >> >> >>>> >> > > > > above, since it will create problems with support.
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > For example, if we support the new local file url
> > >> >>loading
> > >> >> >>>>API
> > >> >> >>>> >> > function
> > >> >> >>>> >> > > in
> > >> >> >>>> >> > > > > iOS 8.2.0 (speculated) -- and a user is on 8.0.2,
> > what
> > >> >> >>>>then?
> > >> >> >>>>You
> > >> >> >>>> >> > would
> > >> >> >>>> >> > > > not
> > >> >> >>>> >> > > > > have WKWebView support for that user, and you would
> > use
> > >> >> >>>> >>UIWebView
> > >> >> >>>> >> > > > instead.
> > >> >> >>>> >> > > > > This will just be confusing, and leads to problems.
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > With the embedded local web server method, you can
> > >> >>support
> > >> >> >>>> >>**any**
> > >> >> >>>> >> > > > version
> > >> >> >>>> >> > > > > of iOS 8.x.
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > ## Embrace Embedded Local Web Server Method
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > I have a Cordova plugin that implements this, and
> it
> > >> >>should
> > >> >> >>>>work
> > >> >> >>>> >> with
> > >> >> >>>> >> > > > > cordova-ios 3.7.0:
> > >> >> >>>> >> > > > > https://github.com/shazron/CordovaLocalWebServer
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > It dynamically updates the <access> tag value when
> it
> > >> >> >>>>loads,
> > >> >> >>>> >> > overriding
> > >> >> >>>> >> > > > it
> > >> >> >>>> >> > > > > to the actual location and port. Since it is a
> > plugin,
> > >> >>it
> > >> >> >>>>can be
> > >> >> >>>> >> > > > swappable
> > >> >> >>>> >> > > > > (for whatever reason).
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > It does not solve the problem where any
> backgrounded
> > >> app
> > >> >> >>>>can
> > >> >> >>>> >>access
> > >> >> >>>> >> > our
> > >> >> >>>> >> > > > > local web server.
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > ## Future Steps
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > This plugin is already working in cordova-ios 3.7.0
> > >> >> >>>> >>(un-released,
> > >> >> >>>> >> up
> > >> >> >>>> >> > > next
> > >> >> >>>> >> > > > > for vote release).
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > The wkwebview branch:
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > 1. Needs be rebased
> > >> >> >>>> >> > > > > 2. Needs to be re-tested
> > >> >> >>>> >> > > > > 3. issues in CB-7043 that relate to the wkwebview
> > have
> > >> >>to
> > >> >> >>>>be
> > >> >> >>>> >> resolved
> > >> >> >>>> >> > > > > 4. branch presented for review to other committers
> > >> >> >>>> >> > > > > 5. resolve any comments and issues from (4)
> > >> >> >>>> >> > > > > 6. wkwebview branch integrated into master
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > I will work on these items next after getting
> > >> >>cordova-ios
> > >> >> >>>>3.7.0
> > >> >> >>>> >> out.
> > >> >> >>>> >> > > Any
> > >> >> >>>> >> > > > > help is welcome.
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > ## Migration Issues
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > If you are migrating to WKWebView from UIWebView,
> you
> > >> >>will
> > >> >> >>>>lose
> > >> >> >>>> >> some
> > >> >> >>>> >> > > > > functionality.
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > > > 1. No more whitelist feature (NSURLProtocol is not
> > >> >> >>>>supported
> > >> >> >>>>in
> > >> >> >>>> >> > > > WKWebView)
> > >> >> >>>> >> > > > > 2. Your XmlHttpRequest calls now need to be CORS
> > >> >>compliant
> > >> >> >>>> >>(this is
> > >> >> >>>> >> > > still
> > >> >> >>>> >> > > > > true if loaded through a file:// url)
> > >> >> >>>> >> > > > > 3. HTML5 offline application cache is not available
> > in
> > >> >> >>>> >>WKWebView (
> > >> >> >>>> >> > > > > https://devforums.apple.com/message/1060452)
> > >> >> >>>> >> > > > >
> > >> >> >>>> >> > > >
> > >> >> >>>> >> > >
> > >> >> >>>> >> >
> > >> >> >>>> >>
> > >> >> >>>>
> > >> >> >>>>
> > >> >> >>>>
> > >>
> >>---------------------------------------------------------------------
> > >> >> >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> >> >>>> For additional commands, e-mail: dev-help@cordova.apache.org
> > >> >> >>>>
> > >> >> >>>>
> > >> >> >>>>
> > >>
> >>---------------------------------------------------------------------
> > >> >> >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> >> >>>> For additional commands, e-mail: dev-help@cordova.apache.org
> > >> >> >>>>
> > >> >> >>>>
> > >> >> >>
> > >> >> >
> > >> >>
> > >> >>
> > >> >>
> ---------------------------------------------------------------------
> > >> >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> >> For additional commands, e-mail: dev-help@cordova.apache.org
> > >> >>
> > >>
> > >>
> > >
> >
>
Re: [iOS 8] WKWebView moving forward
Posted by tommy-carlos williams <to...@devgeeks.org>.
I had much less success… it doesn’t play well with other legacy plugins, does it?
--
tommy-carlos williams
On 11 November 2014 at 03:00:30, Michal Mocny (mmocny@chromium.org) wrote:
Success! I did indeed have to add the framework manually.
Thanks for instructions.
On Thu, Nov 6, 2014 at 7:49 PM, Shazron <sh...@gmail.com> wrote:
> There have been major changes to the `wkwebview` branch of `cordova-ios`.
> The `WKWebView` functionality has been moved to a plugin in the
> `cordova-plugins` repo.
>
> So, for now you can do:
>
> cordova create wkwvtest test.project wkwvtest
> cd wkwvtest
> cordova platform add ios@wkwebview --usegit
> cordova plugin add
> https://github.com/apache/cordova-plugins.git#master:wkwebview-engine
>
> Modify the root `config.xml` and edit this value to:
>
> <content src="http://localhost:0" />
>
> Then:
>
> cordova emulate
>
> You might get a build error, this is a `plugman` bug that doesn't install
> `WebKit.framework` properly even though it is defined in plugin.xml. You
> might have to do a:
>
> open -a Xcode platforms/ios
>
> ...and add the framework manually.
>
> On Thu, Nov 6, 2014 at 11:15 AM, Shazron <sh...@gmail.com> wrote:
>
> > Thanks Tony - I'll look at that PR when I have some time.
> >
> > Yesterday I did some major work to isolate the webviews into plugins
> > (CDVWKWebViewEngine, CDVUIWebViewEngine). This way we can reduce the risk
> > by extracting the WKWebView items into a plugin, and the core has no
> > dependency on WebKit.framework anymore, plus speedy (well, speedier)
> > updates if it needs updating. The CDVUIWebViewEngine will remain in the
> > core as the default engine. I'm still working on this, but it already
> works
> > currently. I'm abstracting things out more, and removing code from the
> > CDVViewController which has become unwieldy.
> >
> > Swapping out engines would use the preference:
> > <preference name="CordovaWebViewEngine" value="CDVWKWebViewEngine" />
> >
> > Any new web engine needs to implement the new CDVWebViewEngineProtocol
> > protocol, and installed as a plugin.
> >
> > On Mon, Nov 3, 2014 at 6:55 PM, Homer, Tony <to...@intel.com>
> wrote:
> >
> >> I have already forked it and made the changes in a topic branch.
> >> I was originally thinking that I would make 2 topic branches: 1 for
> >> localhost-only and 1 for auth tokens.
> >> However, after I finished the first set of changes I realized that the
> >> second set would be dependent on the first.
> >> I’ll submit a pull request tomorrow for you to look at - I’ll be happy
> to
> >> redo it as multiple branches if that makes sense.
> >>
> >> I got a little sidetracked with local web server plugin, but I’ve also
> >> forked cordova-ios and made a topic branch from wkwebview.
> >> I'll start working on some of the changes I proposed earlier in this
> >> thread tomorrow (for plugins like camera that return file:// urls,
> etc.).
> >>
> >> Tony
> >>
> >> On 11/3/14, 7:23 PM, "Shazron" <sh...@gmail.com> wrote:
> >>
> >> >Thanks Tony for all the investigation. Please do fork the local web
> >> server
> >> >plugin and put all your work in topic branches for eventual pull
> requests
> >> >to the main repo.
> >> >
> >> >This is precisely why the local web server is a plugin, and not in the
> >> >core. I don't profess to be a security expert, and we can update this
> >> >plugin to cover most of the security cases or someone else can provide
> >> >their better plugin. I don't think this needs to be bulletproof, not
> that
> >> >we can entirely be (has there ever been a Security Update by Apple that
> >> >*didn't* include a WebKit vulnerability?)
> >> >
> >> >I'd like to get the cordova-ios/wkwebview branch back into the mainline
> >> as
> >> >soon as possible, but under an experimental flag (--experimental ?)
> for
> >> >bin/create. This will choose a new template that has WebKit.framework
> in
> >> >it, which will also define a macro to conditionally compile the new
> bits
> >> >in
> >> >(I haven't added the macros yet in the topic branch).
> >> >
> >> >
> >> >
> >> >
> >> >On Mon, Nov 3, 2014 at 7:27 AM, Homer, Tony <to...@intel.com>
> >> wrote:
> >> >
> >> >> I spent a lot of time thinking about ways to avoid replay attacks for
> >> >>the
> >> >> local web server plugin this weekend.
> >> >>
> >> >> Specifically, I felt like there should be a way to take advantage of
> >> the
> >> >> fact that the client and the server are running in the same process.
> >> >> I thought this might enable some kind of sideband (non-http)
> >> >> authentication possibility.
> >> >> The 2 possibilities I was most interested in, but eventually
> concluded
> >> >>are
> >> >> not practical were:
> >> >> 1. unique token per http request - not practical because there is no
> >> per
> >> >> http request event available
> >> >> 2. a whitelist of “remote” ports - not practical because there is no
> >> >> simple way to get a list of ports in use by WKWebView
> >> >>
> >> >> After going down this rathole and coming up empty, I reconsidered the
> >> >> original problem and came to the following conclusions.
> >> >> 1. restricting requests to localhost-only limits “attacks” to
> >> >>backgrounded
> >> >> apps
> >> >> 2. including a token in the requests will prevent backgrounded apps
> >> from
> >> >> being able to successfully make unwanted requests
> >> >> 3. the token is vulnerable to network analysis, but that cannot be
> done
> >> >>on
> >> >> device
> >> >>
> >> >> Therefore, vulnerability is limited to the case where the there is
> >> >> (1) a “hostile" app installed on device and running in the background
> >> >>and
> >> >> (2) the user’s device is connected to a wi-fi network where an
> attacker
> >> >>is
> >> >> able to perform network analysis to capture the token.
> >> >> In this case, the attacker could just inspect the HTTP traffic
> instead
> >> >>of
> >> >> capturing the token and sending it to their backgrounded app.
> >> >> In other words, it seems that replay attacks are possible but not
> >> >>useful.
> >> >> If we care about the “hostile wifi network” case, we need something
> >> like
> >> >> SSL.
> >> >>
> >> >> On 11/1/14, 4:28 PM, "Homer, Tony" <to...@intel.com> wrote:
> >> >>
> >> >> >I started looking at how to make the camera plugin be able to work
> in
> >> >> >WKWebView.
> >> >> >Before, I had mentioned intercepting resource requests as a way to
> fix
> >> >>the
> >> >> >file:// requests.
> >> >> >However, WKWebView does not offer a way to intercept resource
> requests
> >> >>so
> >> >> >that won’t work.
> >> >> >:/
> >> >> >
> >> >> >Andrew had suggested introducing some proxy paths as a way to deal
> >> with
> >> >> >the path problems, which seems fine.
> >> >> >On the other hand, the request handlers could just inspect the path
> in
> >> >>the
> >> >> >request and do the right thing - are the proxy paths needed?
> >> >> >I think implicit in those comments was a suggestion that the
> affected
> >> >> >plugins such as camera could return URLs using those paths.
> >> >> >The thing about changing camera and file plugins to support
> localhost
> >> >>that
> >> >> >bothers me, is that now those core plugins effectively support a
> >> >>non-core
> >> >> >plugin.
> >> >> >Also, other (on-cordova) plugins that depend on file protocol will
> be
> >> >> >incompatible with the local web server wkwebview solution (unless
> they
> >> >> >make changes to support it).
> >> >> >
> >> >> >I wonder if it would be better to handle this in CDVPluginResult?
> >> >> >A hook could be added to initWithStatus and exposed to plugins.
> >> >> >Then the SALocalWebServer plugin can use the hook to inspect the
> >> >>message
> >> >> >and fix it, if it is a file:// URL.
> >> >> >So, for example, when camera calls CDVPluginResult
> >> >> >resultWithStatus:messageAsString and passes in a file URL,
> >> >>SALocalServer
> >> >> >can get a chance to inspect and modify the result – changing it to
> an
> >> >> >http:localhost URL. It could simply replace the file protocol with
> >> >> >http://localhost:port, then the handler could decode the path
> before
> >> >> >building the response.
> >> >> >This is ugly, but it would prevent the need to change the camera and
> >> >>file
> >> >> >and should allow other non-cordova plugins that depend on file://
> URLs
> >> >>to
> >> >> >work.
> >> >> >
> >> >> >
> >> >> >Tony
> >> >> >
> >> >> >On 10/31/14, 2:03 PM, "Homer, Tony" <to...@intel.com> wrote:
> >> >> >
> >> >> >>I started with cookies in my POC, but I was concerned about replay
> >> >> >>attacks.
> >> >> >>I couldn’t think of a way to avoid replay vulnerability with
> cookies
> >> >> >>(without SSL), so I was going to switch to the side channel
> approach
> >> I
> >> >> >>tried to describe. Do you think replay vulnerability is
> irrelevant?
> >> >>I’m
> >> >> >>not a security guy, so I wasn’t sure if it mattered or not. That’s
> >> >> >>actually one of the things I was hoping to get feedback about.
> >> >> >>
> >> >> >>I guess I don’t follow how CORS relates to the camera plugin, does
> it
> >> >>use
> >> >> >>XHR? Maybe you can elaborate?
> >> >> >>I expect I’ll see it when I try the camera plugin from WKWebView,
> >> just
> >> >> >>didn’t get around to it yet.
> >> >> >>The only thing that jumps out at me is that you get a file:// url
> >> >>back -
> >> >> >>we could change that.
> >> >> >>Or maybe intercept file:// requests in the plugin? If it’s just a
> >> >>path
> >> >> >>problem, maybe we could intercept the request, fix the path, then
> >> >>respond
> >> >> >>with the right thing...
> >> >> >>
> >> >> >>Tony
> >> >> >>
> >> >> >>On 10/31/14, 1:19 PM, "Andrew Grieve" <ag...@chromium.org>
> wrote:
> >> >> >>
> >> >> >>>Unless you're having the server proxy requests to remote sites, I
> >> >>don't
> >> >> >>>think CORS headers are necessary.
> >> >> >>>
> >> >> >>>Tony - awesome stuff! absolutely doing it right. More
> >> >>technical-focused
> >> >> >>>discussion the better :). Using cookies seems the best way to me
> >> >>since
> >> >> >>>that
> >> >> >>>covers all requests. Adding headers works only for XHRs.
> >> >> >>>
> >> >> >>>On Fri, Oct 31, 2014 at 12:12 PM, Kirk Shoop (MS OPEN TECH) <
> >> >> >>>Kirk.Shoop@microsoft.com> wrote:
> >> >> >>>
> >> >> >>>> Yes, the handler should be able to add CORS headers to its
> >> >>responses
> >> >> >>>>that
> >> >> >>>> will enable requests from any origin.
> >> >> >>>>
> >> >> >>>> For instance adding 'Access-Control-Allow-Origin: *' would allow
> >> >>any
> >> >> >>>> origin to make a request from the local server.
> >> >> >>>>
> >> >>
> http://www.w3.org/TR/cors/#access-control-allow-origin-response-header
> >> >> >>>>
> >> >> >>>> Similarly Access-Control-Allow-Methods and
> >> >> >>>>Access-Control-Allow-Headers
> >> >> >>>> could be used to define valid requests.
> >> >> >>>>
> >> >> >>>> Kirk
> >> >> >>>>
> >> >> >>>> Developer
> >> >> >>>> Microsoft Open Technologies, Inc.
> >> >> >>>>
> >> >> >>>> -----Original Message-----
> >> >> >>>> From: Homer, Tony [mailto:tony.homer@intel.com]
> >> >> >>>> Sent: Friday, October 31, 2014 8:40 AM
> >> >> >>>> To: dev@cordova.apache.org
> >> >> >>>> Subject: Re: [iOS 8] WKWebView moving forward
> >> >> >>>>
> >> >> >>>> Last night I added a handler to the Local Web Server plugin that
> >> >> >>>>returns
> >> >> >>>> 403 for non-localhost requests.
> >> >> >>>> The handler also has a prototype token system to restrict
> requests
> >> >>to
> >> >> >>>>the
> >> >> >>>> app, but I need to change the approach a bit.
> >> >> >>>> Currently I set a cookie and the handler just checks for the
> >> cookie
> >> >> >>>>and
> >> >> >>>> returns 403 if it is missing.
> >> >> >>>> This is susceptible to replay attacks from backgrounded apps -
> not
> >> >> >>>>sure
> >> >> >>>>if
> >> >> >>>> that is important or not.
> >> >> >>>>
> >> >> >>>> I¹m going to investigate adding a map to the plugin, then add an
> >> >>entry
> >> >> >>>>for
> >> >> >>>> every request.
> >> >> >>>> The entry will be a hash of the request and a random number.
> >> >> >>>>
> >> >> >>>> I¹ll have to wire up support for overriding url loads so that I
> >> can
> >> >> >>>>add
> >> >> >>>> the header with the random number to the request.
> >> >> >>>> Then the request handler will look the entry up in the map and
> >> >>remove
> >> >> >>>>it -
> >> >> >>>> this should eliminate re-playability.
> >> >> >>>>
> >> >> >>>> I¹m not sure about the CORS issue with camera pluginŠ I¹ll be
> >> >>curious
> >> >> >>>>to
> >> >> >>>> test it - maybe it could be addressed by modifying the response
> in
> >> >>the
> >> >> >>>> GCDWebServer handler?
> >> >> >>>>
> >> >> >>>> Tony
> >> >> >>>>
> >> >> >>>> P.S. This is my first attempt participating in discussion on the
> >> >>list
> >> >> >>>>-
> >> >> >>>> let me know if I¹m doing it wrong!
> >> >> >>>> Am I wasting my time investigating this? Should I just leave it
> >> >> >>>>Shazron?
> >> >> >>>>
> >> >> >>>> On 10/30/14, 9:52 PM, "Andrew Grieve" <ag...@chromium.org>
> >> wrote:
> >> >> >>>>
> >> >> >>>> >On Thu, Oct 30, 2014 at 5:05 PM, Shazron <sh...@gmail.com>
> >> >>wrote:
> >> >> >>>> >
> >> >> >>>> >> The port conflict situation has been solved with the latest
> >> >>version
> >> >> >>>> >>of the plugin. Passing in a port of "0" will choose a random
> >> >>port.
> >> >> >>>> >>More details in the plugin's README.md
> >> >> >>>> >>
> >> >> >>>> >Awesome! Why even allow a non-random port?
> >> >> >>>> >Also learned today that in chrome, webcrypto API is disabled
> for
> >> >>http
> >> >> >>>> >origins, but enabled for https. Not sure if this is true for
> >> >>Safari
> >> >> >>>>as
> >> >> >>>> >well, but certainly this change will be a can of worms!
> >> >> >>>> >
> >> >> >>>> >
> >> >> >>>> >>
> >> >> >>>> >> Ouch - didn't think about Camera plugin and File plugin
> impact.
> >> >> >>>>That
> >> >> >>>> >>proxy thing might work, as long as there are no folder name
> >> >> >>>> >>collisions.
> >> >> >>>> >>
> >> >> >>>> >Prefixing all resources into a fake top-level directory will
> >> >> >>>>eliminate
> >> >> >>>> >the folder name collision problem I think.
> >> >> >>>> >
> >> >> >>>> >
> >> >> >>>> >>
> >> >> >>>> >> My point regarding mixing WKWebView and UIWebView on iOS 8
> is,
> >> >>if
> >> >> >>>>you
> >> >> >>>> >>have a user on iOS 8.x, you want all users on that iOS
> version
> >> >>to
> >> >> >>>> >>have the same experience, and for bug reporting purposes.
> >> >> >>>> >
> >> >> >>>> >
> >> >> >>>> >> On Wed, Oct 29, 2014 at 5:11 PM, Andrew Grieve
> >> >> >>>><ag...@chromium.org>
> >> >> >>>> >> wrote:
> >> >> >>>> >>
> >> >> >>>> >> > We could restrict access to the webserver by stuffing a
> >> cookie
> >> >> >>>>into
> >> >> >>>> >>the
> >> >> >>>> >> > webview with an access token, then have the server just 500
> >> on
> >> >> >>>>any
> >> >> >>>> >> request
> >> >> >>>> >> > missing the cookie. We should also be able to restrict
> >> >>external
> >> >> >>>> >>requests
> >> >> >>>> >> > just by listening on 127.0.0.1 instead of 0.0.0.0 (doesn't
> >> >>look
> >> >> >>>> >> > like GCDWebServer supports this, but we can hack it in).
> >> >> >>>> >> >
> >> >> >>>> >> > The problem of port conflicts is annoying though. Maybe we
> >> try
> >> >> >>>>random
> >> >> >>>> >> ports
> >> >> >>>> >> > until one works? Is there any need to use the same port for
> >> >> >>>>multiple
> >> >> >>>> >> runs?
> >> >> >>>> >> >
> >> >> >>>> >> > The CORS thing is sad, because it also means things like
> >> >>Camera
> >> >> >>>>plugin
> >> >> >>>> >> will
> >> >> >>>> >> > be broken (can't use resulting URL in <img>).
> >> >> >>>> >> >
> >> >> >>>> >> > Although we might just do (this is different than the
> current
> >> >> >>>>mapping
> >> >> >>>> >>in
> >> >> >>>> >> > the plugin):
> >> >> >>>> >> > http://localhost:RANDOM_PORT/www
> >> >> >>>> >> > http://localhost:RANDOM_PORT/asset-library
> >> >> >>>> >> > http://localhost:RANDOM_PORT/file-system
> >> >> >>>> >> >
> >> >> >>>> >> > to proxy the three locations.
> >> >> >>>> >> >
> >> >> >>>> >> > This also means we can't use FileEntry.toURL() and have it
> >> >>work,
> >> >> >>>> >>unless
> >> >> >>>> >> > toURL returns http://localhost:RANDOM_PORT/file-system/...
> >> >> >>>>Maybe
> >> >> >>>> >> that's
> >> >> >>>> >> > fine?
> >> >> >>>> >> >
> >> >> >>>> >> >
> >> >> >>>> >> > I don't think it's weird that an app will need to support
> >> >> >>>>WKWebView on
> >> >> >>>> >> some
> >> >> >>>> >> > OS versions, and UIWebView on others. That's already the
> case
> >> >>to
> >> >> >>>> >>support
> >> >> >>>> >> > iOS 7.
> >> >> >>>> >> >
> >> >> >>>> >> >
> >> >> >>>> >> >
> >> >> >>>> >> > On Wed, Oct 29, 2014 at 6:22 PM, Shazron <
> shazron@gmail.com>
> >> >> >>>>wrote:
> >> >> >>>> >> >
> >> >> >>>> >> > > This does not preclude using the file url API function I
> >> >> >>>>suppose.
> >> >> >>>> >> Here's
> >> >> >>>> >> > a
> >> >> >>>> >> > > flowchart on how I think it would work:
> >> >> >>>> >>http://i.imgur.com/zq4zreN.png
> >> >> >>>> >> > >
> >> >> >>>> >> > >
> >> >> >>>> >> > > On Wed, Oct 29, 2014 at 2:48 PM, Tommy Williams
> >> >> >>>><tommy@devgeeks.org
> >> >> >>>> >
> >> >> >>>> >> > > wrote:
> >> >> >>>> >> > >
> >> >> >>>> >> > > > This whole thing reeks of sadness and pain.
> >> >> >>>> >> > > >
> >> >> >>>> >> > > > The security implications of this will have to be
> >> >>considered
> >> >> >>>>very
> >> >> >>>> >> > > > carefully.
> >> >> >>>> >> > > > On 29 Oct 2014 16:40, "Shazron" <sh...@apache.org>
> >> >>wrote:
> >> >> >>>> >> > > >
> >> >> >>>> >> > > > > ## What We Know So Far
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > 1. Because of the file:// url loading bug, we
> couldn't
> >> >> >>>>support
> >> >> >>>> >>the
> >> >> >>>> >> > > > > WKWebView in the iOS 8 GM release. It has since been
> >> >>fixed,
> >> >> >>>>for
> >> >> >>>> >> > release
> >> >> >>>> >> > > > > post iOS 8.1 (not sure when), through a new WKWebView
> >> >>API
> >> >> >>>> >>function
> >> >> >>>> >> (
> >> >> >>>> >> > > > > http://trac.webkit.org/changeset/174029/trunk)
> >> >> >>>> >> > > > > 2. The alternative is embedding a local web server
> and
> >> >> >>>>serving
> >> >> >>>> >> assets
> >> >> >>>> >> > > > from
> >> >> >>>> >> > > > > that
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > ## Abandon file:// url Loading API Method
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > My proposal is, we abandon the local file:// url
> >> loading
> >> >> >>>>method
> >> >> >>>> >>in
> >> >> >>>> >> > (1)
> >> >> >>>> >> > > > > above, since it will create problems with support.
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > For example, if we support the new local file url
> >> >>loading
> >> >> >>>>API
> >> >> >>>> >> > function
> >> >> >>>> >> > > in
> >> >> >>>> >> > > > > iOS 8.2.0 (speculated) -- and a user is on 8.0.2,
> what
> >> >> >>>>then?
> >> >> >>>>You
> >> >> >>>> >> > would
> >> >> >>>> >> > > > not
> >> >> >>>> >> > > > > have WKWebView support for that user, and you would
> use
> >> >> >>>> >>UIWebView
> >> >> >>>> >> > > > instead.
> >> >> >>>> >> > > > > This will just be confusing, and leads to problems.
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > With the embedded local web server method, you can
> >> >>support
> >> >> >>>> >>**any**
> >> >> >>>> >> > > > version
> >> >> >>>> >> > > > > of iOS 8.x.
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > ## Embrace Embedded Local Web Server Method
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > I have a Cordova plugin that implements this, and it
> >> >>should
> >> >> >>>>work
> >> >> >>>> >> with
> >> >> >>>> >> > > > > cordova-ios 3.7.0:
> >> >> >>>> >> > > > > https://github.com/shazron/CordovaLocalWebServer
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > It dynamically updates the <access> tag value when it
> >> >> >>>>loads,
> >> >> >>>> >> > overriding
> >> >> >>>> >> > > > it
> >> >> >>>> >> > > > > to the actual location and port. Since it is a
> plugin,
> >> >>it
> >> >> >>>>can be
> >> >> >>>> >> > > > swappable
> >> >> >>>> >> > > > > (for whatever reason).
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > It does not solve the problem where any backgrounded
> >> app
> >> >> >>>>can
> >> >> >>>> >>access
> >> >> >>>> >> > our
> >> >> >>>> >> > > > > local web server.
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > ## Future Steps
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > This plugin is already working in cordova-ios 3.7.0
> >> >> >>>> >>(un-released,
> >> >> >>>> >> up
> >> >> >>>> >> > > next
> >> >> >>>> >> > > > > for vote release).
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > The wkwebview branch:
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > 1. Needs be rebased
> >> >> >>>> >> > > > > 2. Needs to be re-tested
> >> >> >>>> >> > > > > 3. issues in CB-7043 that relate to the wkwebview
> have
> >> >>to
> >> >> >>>>be
> >> >> >>>> >> resolved
> >> >> >>>> >> > > > > 4. branch presented for review to other committers
> >> >> >>>> >> > > > > 5. resolve any comments and issues from (4)
> >> >> >>>> >> > > > > 6. wkwebview branch integrated into master
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > I will work on these items next after getting
> >> >>cordova-ios
> >> >> >>>>3.7.0
> >> >> >>>> >> out.
> >> >> >>>> >> > > Any
> >> >> >>>> >> > > > > help is welcome.
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > ## Migration Issues
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > If you are migrating to WKWebView from UIWebView, you
> >> >>will
> >> >> >>>>lose
> >> >> >>>> >> some
> >> >> >>>> >> > > > > functionality.
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > 1. No more whitelist feature (NSURLProtocol is not
> >> >> >>>>supported
> >> >> >>>>in
> >> >> >>>> >> > > > WKWebView)
> >> >> >>>> >> > > > > 2. Your XmlHttpRequest calls now need to be CORS
> >> >>compliant
> >> >> >>>> >>(this is
> >> >> >>>> >> > > still
> >> >> >>>> >> > > > > true if loaded through a file:// url)
> >> >> >>>> >> > > > > 3. HTML5 offline application cache is not available
> in
> >> >> >>>> >>WKWebView (
> >> >> >>>> >> > > > > https://devforums.apple.com/message/1060452)
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > >
> >> >> >>>> >> > >
> >> >> >>>> >> >
> >> >> >>>> >>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >>---------------------------------------------------------------------
> >> >> >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> >> >>>> For additional commands, e-mail: dev-help@cordova.apache.org
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >>---------------------------------------------------------------------
> >> >> >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> >> >>>> For additional commands, e-mail: dev-help@cordova.apache.org
> >> >> >>>>
> >> >> >>>>
> >> >> >>
> >> >> >
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> >> For additional commands, e-mail: dev-help@cordova.apache.org
> >> >>
> >>
> >>
> >
>
Re: [iOS 8] WKWebView moving forward
Posted by Michal Mocny <mm...@chromium.org>.
Success! I did indeed have to add the framework manually.
Thanks for instructions.
On Thu, Nov 6, 2014 at 7:49 PM, Shazron <sh...@gmail.com> wrote:
> There have been major changes to the `wkwebview` branch of `cordova-ios`.
> The `WKWebView` functionality has been moved to a plugin in the
> `cordova-plugins` repo.
>
> So, for now you can do:
>
> cordova create wkwvtest test.project wkwvtest
> cd wkwvtest
> cordova platform add ios@wkwebview --usegit
> cordova plugin add
> https://github.com/apache/cordova-plugins.git#master:wkwebview-engine
>
> Modify the root `config.xml` and edit this value to:
>
> <content src="http://localhost:0" />
>
> Then:
>
> cordova emulate
>
> You might get a build error, this is a `plugman` bug that doesn't install
> `WebKit.framework` properly even though it is defined in plugin.xml. You
> might have to do a:
>
> open -a Xcode platforms/ios
>
> ...and add the framework manually.
>
> On Thu, Nov 6, 2014 at 11:15 AM, Shazron <sh...@gmail.com> wrote:
>
> > Thanks Tony - I'll look at that PR when I have some time.
> >
> > Yesterday I did some major work to isolate the webviews into plugins
> > (CDVWKWebViewEngine, CDVUIWebViewEngine). This way we can reduce the risk
> > by extracting the WKWebView items into a plugin, and the core has no
> > dependency on WebKit.framework anymore, plus speedy (well, speedier)
> > updates if it needs updating. The CDVUIWebViewEngine will remain in the
> > core as the default engine. I'm still working on this, but it already
> works
> > currently. I'm abstracting things out more, and removing code from the
> > CDVViewController which has become unwieldy.
> >
> > Swapping out engines would use the preference:
> > <preference name="CordovaWebViewEngine" value="CDVWKWebViewEngine" />
> >
> > Any new web engine needs to implement the new CDVWebViewEngineProtocol
> > protocol, and installed as a plugin.
> >
> > On Mon, Nov 3, 2014 at 6:55 PM, Homer, Tony <to...@intel.com>
> wrote:
> >
> >> I have already forked it and made the changes in a topic branch.
> >> I was originally thinking that I would make 2 topic branches: 1 for
> >> localhost-only and 1 for auth tokens.
> >> However, after I finished the first set of changes I realized that the
> >> second set would be dependent on the first.
> >> I’ll submit a pull request tomorrow for you to look at - I’ll be happy
> to
> >> redo it as multiple branches if that makes sense.
> >>
> >> I got a little sidetracked with local web server plugin, but I’ve also
> >> forked cordova-ios and made a topic branch from wkwebview.
> >> I'll start working on some of the changes I proposed earlier in this
> >> thread tomorrow (for plugins like camera that return file:// urls,
> etc.).
> >>
> >> Tony
> >>
> >> On 11/3/14, 7:23 PM, "Shazron" <sh...@gmail.com> wrote:
> >>
> >> >Thanks Tony for all the investigation. Please do fork the local web
> >> server
> >> >plugin and put all your work in topic branches for eventual pull
> requests
> >> >to the main repo.
> >> >
> >> >This is precisely why the local web server is a plugin, and not in the
> >> >core. I don't profess to be a security expert, and we can update this
> >> >plugin to cover most of the security cases or someone else can provide
> >> >their better plugin. I don't think this needs to be bulletproof, not
> that
> >> >we can entirely be (has there ever been a Security Update by Apple that
> >> >*didn't* include a WebKit vulnerability?)
> >> >
> >> >I'd like to get the cordova-ios/wkwebview branch back into the mainline
> >> as
> >> >soon as possible, but under an experimental flag (--experimental ?)
> for
> >> >bin/create. This will choose a new template that has WebKit.framework
> in
> >> >it, which will also define a macro to conditionally compile the new
> bits
> >> >in
> >> >(I haven't added the macros yet in the topic branch).
> >> >
> >> >
> >> >
> >> >
> >> >On Mon, Nov 3, 2014 at 7:27 AM, Homer, Tony <to...@intel.com>
> >> wrote:
> >> >
> >> >> I spent a lot of time thinking about ways to avoid replay attacks for
> >> >>the
> >> >> local web server plugin this weekend.
> >> >>
> >> >> Specifically, I felt like there should be a way to take advantage of
> >> the
> >> >> fact that the client and the server are running in the same process.
> >> >> I thought this might enable some kind of sideband (non-http)
> >> >> authentication possibility.
> >> >> The 2 possibilities I was most interested in, but eventually
> concluded
> >> >>are
> >> >> not practical were:
> >> >> 1. unique token per http request - not practical because there is no
> >> per
> >> >> http request event available
> >> >> 2. a whitelist of “remote” ports - not practical because there is no
> >> >> simple way to get a list of ports in use by WKWebView
> >> >>
> >> >> After going down this rathole and coming up empty, I reconsidered the
> >> >> original problem and came to the following conclusions.
> >> >> 1. restricting requests to localhost-only limits “attacks” to
> >> >>backgrounded
> >> >> apps
> >> >> 2. including a token in the requests will prevent backgrounded apps
> >> from
> >> >> being able to successfully make unwanted requests
> >> >> 3. the token is vulnerable to network analysis, but that cannot be
> done
> >> >>on
> >> >> device
> >> >>
> >> >> Therefore, vulnerability is limited to the case where the there is
> >> >> (1) a “hostile" app installed on device and running in the background
> >> >>and
> >> >> (2) the user’s device is connected to a wi-fi network where an
> attacker
> >> >>is
> >> >> able to perform network analysis to capture the token.
> >> >> In this case, the attacker could just inspect the HTTP traffic
> instead
> >> >>of
> >> >> capturing the token and sending it to their backgrounded app.
> >> >> In other words, it seems that replay attacks are possible but not
> >> >>useful.
> >> >> If we care about the “hostile wifi network” case, we need something
> >> like
> >> >> SSL.
> >> >>
> >> >> On 11/1/14, 4:28 PM, "Homer, Tony" <to...@intel.com> wrote:
> >> >>
> >> >> >I started looking at how to make the camera plugin be able to work
> in
> >> >> >WKWebView.
> >> >> >Before, I had mentioned intercepting resource requests as a way to
> fix
> >> >>the
> >> >> >file:// requests.
> >> >> >However, WKWebView does not offer a way to intercept resource
> requests
> >> >>so
> >> >> >that won’t work.
> >> >> >:/
> >> >> >
> >> >> >Andrew had suggested introducing some proxy paths as a way to deal
> >> with
> >> >> >the path problems, which seems fine.
> >> >> >On the other hand, the request handlers could just inspect the path
> in
> >> >>the
> >> >> >request and do the right thing - are the proxy paths needed?
> >> >> >I think implicit in those comments was a suggestion that the
> affected
> >> >> >plugins such as camera could return URLs using those paths.
> >> >> >The thing about changing camera and file plugins to support
> localhost
> >> >>that
> >> >> >bothers me, is that now those core plugins effectively support a
> >> >>non-core
> >> >> >plugin.
> >> >> >Also, other (on-cordova) plugins that depend on file protocol will
> be
> >> >> >incompatible with the local web server wkwebview solution (unless
> they
> >> >> >make changes to support it).
> >> >> >
> >> >> >I wonder if it would be better to handle this in CDVPluginResult?
> >> >> >A hook could be added to initWithStatus and exposed to plugins.
> >> >> >Then the SALocalWebServer plugin can use the hook to inspect the
> >> >>message
> >> >> >and fix it, if it is a file:// URL.
> >> >> >So, for example, when camera calls CDVPluginResult
> >> >> >resultWithStatus:messageAsString and passes in a file URL,
> >> >>SALocalServer
> >> >> >can get a chance to inspect and modify the result – changing it to
> an
> >> >> >http:localhost URL. It could simply replace the file protocol with
> >> >> >http://localhost:port, then the handler could decode the path
> before
> >> >> >building the response.
> >> >> >This is ugly, but it would prevent the need to change the camera and
> >> >>file
> >> >> >and should allow other non-cordova plugins that depend on file://
> URLs
> >> >>to
> >> >> >work.
> >> >> >
> >> >> >
> >> >> >Tony
> >> >> >
> >> >> >On 10/31/14, 2:03 PM, "Homer, Tony" <to...@intel.com> wrote:
> >> >> >
> >> >> >>I started with cookies in my POC, but I was concerned about replay
> >> >> >>attacks.
> >> >> >>I couldn’t think of a way to avoid replay vulnerability with
> cookies
> >> >> >>(without SSL), so I was going to switch to the side channel
> approach
> >> I
> >> >> >>tried to describe. Do you think replay vulnerability is
> irrelevant?
> >> >>I’m
> >> >> >>not a security guy, so I wasn’t sure if it mattered or not. That’s
> >> >> >>actually one of the things I was hoping to get feedback about.
> >> >> >>
> >> >> >>I guess I don’t follow how CORS relates to the camera plugin, does
> it
> >> >>use
> >> >> >>XHR? Maybe you can elaborate?
> >> >> >>I expect I’ll see it when I try the camera plugin from WKWebView,
> >> just
> >> >> >>didn’t get around to it yet.
> >> >> >>The only thing that jumps out at me is that you get a file:// url
> >> >>back -
> >> >> >>we could change that.
> >> >> >>Or maybe intercept file:// requests in the plugin? If it’s just a
> >> >>path
> >> >> >>problem, maybe we could intercept the request, fix the path, then
> >> >>respond
> >> >> >>with the right thing...
> >> >> >>
> >> >> >>Tony
> >> >> >>
> >> >> >>On 10/31/14, 1:19 PM, "Andrew Grieve" <ag...@chromium.org>
> wrote:
> >> >> >>
> >> >> >>>Unless you're having the server proxy requests to remote sites, I
> >> >>don't
> >> >> >>>think CORS headers are necessary.
> >> >> >>>
> >> >> >>>Tony - awesome stuff! absolutely doing it right. More
> >> >>technical-focused
> >> >> >>>discussion the better :). Using cookies seems the best way to me
> >> >>since
> >> >> >>>that
> >> >> >>>covers all requests. Adding headers works only for XHRs.
> >> >> >>>
> >> >> >>>On Fri, Oct 31, 2014 at 12:12 PM, Kirk Shoop (MS OPEN TECH) <
> >> >> >>>Kirk.Shoop@microsoft.com> wrote:
> >> >> >>>
> >> >> >>>> Yes, the handler should be able to add CORS headers to its
> >> >>responses
> >> >> >>>>that
> >> >> >>>> will enable requests from any origin.
> >> >> >>>>
> >> >> >>>> For instance adding 'Access-Control-Allow-Origin: *' would allow
> >> >>any
> >> >> >>>> origin to make a request from the local server.
> >> >> >>>>
> >> >>
> http://www.w3.org/TR/cors/#access-control-allow-origin-response-header
> >> >> >>>>
> >> >> >>>> Similarly Access-Control-Allow-Methods and
> >> >> >>>>Access-Control-Allow-Headers
> >> >> >>>> could be used to define valid requests.
> >> >> >>>>
> >> >> >>>> Kirk
> >> >> >>>>
> >> >> >>>> Developer
> >> >> >>>> Microsoft Open Technologies, Inc.
> >> >> >>>>
> >> >> >>>> -----Original Message-----
> >> >> >>>> From: Homer, Tony [mailto:tony.homer@intel.com]
> >> >> >>>> Sent: Friday, October 31, 2014 8:40 AM
> >> >> >>>> To: dev@cordova.apache.org
> >> >> >>>> Subject: Re: [iOS 8] WKWebView moving forward
> >> >> >>>>
> >> >> >>>> Last night I added a handler to the Local Web Server plugin that
> >> >> >>>>returns
> >> >> >>>> 403 for non-localhost requests.
> >> >> >>>> The handler also has a prototype token system to restrict
> requests
> >> >>to
> >> >> >>>>the
> >> >> >>>> app, but I need to change the approach a bit.
> >> >> >>>> Currently I set a cookie and the handler just checks for the
> >> cookie
> >> >> >>>>and
> >> >> >>>> returns 403 if it is missing.
> >> >> >>>> This is susceptible to replay attacks from backgrounded apps -
> not
> >> >> >>>>sure
> >> >> >>>>if
> >> >> >>>> that is important or not.
> >> >> >>>>
> >> >> >>>> I¹m going to investigate adding a map to the plugin, then add an
> >> >>entry
> >> >> >>>>for
> >> >> >>>> every request.
> >> >> >>>> The entry will be a hash of the request and a random number.
> >> >> >>>>
> >> >> >>>> I¹ll have to wire up support for overriding url loads so that I
> >> can
> >> >> >>>>add
> >> >> >>>> the header with the random number to the request.
> >> >> >>>> Then the request handler will look the entry up in the map and
> >> >>remove
> >> >> >>>>it -
> >> >> >>>> this should eliminate re-playability.
> >> >> >>>>
> >> >> >>>> I¹m not sure about the CORS issue with camera pluginŠ I¹ll be
> >> >>curious
> >> >> >>>>to
> >> >> >>>> test it - maybe it could be addressed by modifying the response
> in
> >> >>the
> >> >> >>>> GCDWebServer handler?
> >> >> >>>>
> >> >> >>>> Tony
> >> >> >>>>
> >> >> >>>> P.S. This is my first attempt participating in discussion on the
> >> >>list
> >> >> >>>>-
> >> >> >>>> let me know if I¹m doing it wrong!
> >> >> >>>> Am I wasting my time investigating this? Should I just leave it
> >> >> >>>>Shazron?
> >> >> >>>>
> >> >> >>>> On 10/30/14, 9:52 PM, "Andrew Grieve" <ag...@chromium.org>
> >> wrote:
> >> >> >>>>
> >> >> >>>> >On Thu, Oct 30, 2014 at 5:05 PM, Shazron <sh...@gmail.com>
> >> >>wrote:
> >> >> >>>> >
> >> >> >>>> >> The port conflict situation has been solved with the latest
> >> >>version
> >> >> >>>> >>of the plugin. Passing in a port of "0" will choose a random
> >> >>port.
> >> >> >>>> >>More details in the plugin's README.md
> >> >> >>>> >>
> >> >> >>>> >Awesome! Why even allow a non-random port?
> >> >> >>>> >Also learned today that in chrome, webcrypto API is disabled
> for
> >> >>http
> >> >> >>>> >origins, but enabled for https. Not sure if this is true for
> >> >>Safari
> >> >> >>>>as
> >> >> >>>> >well, but certainly this change will be a can of worms!
> >> >> >>>> >
> >> >> >>>> >
> >> >> >>>> >>
> >> >> >>>> >> Ouch - didn't think about Camera plugin and File plugin
> impact.
> >> >> >>>>That
> >> >> >>>> >>proxy thing might work, as long as there are no folder name
> >> >> >>>> >>collisions.
> >> >> >>>> >>
> >> >> >>>> >Prefixing all resources into a fake top-level directory will
> >> >> >>>>eliminate
> >> >> >>>> >the folder name collision problem I think.
> >> >> >>>> >
> >> >> >>>> >
> >> >> >>>> >>
> >> >> >>>> >> My point regarding mixing WKWebView and UIWebView on iOS 8
> is,
> >> >>if
> >> >> >>>>you
> >> >> >>>> >>have a user on iOS 8.x, you want all users on that iOS
> version
> >> >>to
> >> >> >>>> >>have the same experience, and for bug reporting purposes.
> >> >> >>>> >
> >> >> >>>> >
> >> >> >>>> >> On Wed, Oct 29, 2014 at 5:11 PM, Andrew Grieve
> >> >> >>>><ag...@chromium.org>
> >> >> >>>> >> wrote:
> >> >> >>>> >>
> >> >> >>>> >> > We could restrict access to the webserver by stuffing a
> >> cookie
> >> >> >>>>into
> >> >> >>>> >>the
> >> >> >>>> >> > webview with an access token, then have the server just 500
> >> on
> >> >> >>>>any
> >> >> >>>> >> request
> >> >> >>>> >> > missing the cookie. We should also be able to restrict
> >> >>external
> >> >> >>>> >>requests
> >> >> >>>> >> > just by listening on 127.0.0.1 instead of 0.0.0.0 (doesn't
> >> >>look
> >> >> >>>> >> > like GCDWebServer supports this, but we can hack it in).
> >> >> >>>> >> >
> >> >> >>>> >> > The problem of port conflicts is annoying though. Maybe we
> >> try
> >> >> >>>>random
> >> >> >>>> >> ports
> >> >> >>>> >> > until one works? Is there any need to use the same port for
> >> >> >>>>multiple
> >> >> >>>> >> runs?
> >> >> >>>> >> >
> >> >> >>>> >> > The CORS thing is sad, because it also means things like
> >> >>Camera
> >> >> >>>>plugin
> >> >> >>>> >> will
> >> >> >>>> >> > be broken (can't use resulting URL in <img>).
> >> >> >>>> >> >
> >> >> >>>> >> > Although we might just do (this is different than the
> current
> >> >> >>>>mapping
> >> >> >>>> >>in
> >> >> >>>> >> > the plugin):
> >> >> >>>> >> > http://localhost:RANDOM_PORT/www
> >> >> >>>> >> > http://localhost:RANDOM_PORT/asset-library
> >> >> >>>> >> > http://localhost:RANDOM_PORT/file-system
> >> >> >>>> >> >
> >> >> >>>> >> > to proxy the three locations.
> >> >> >>>> >> >
> >> >> >>>> >> > This also means we can't use FileEntry.toURL() and have it
> >> >>work,
> >> >> >>>> >>unless
> >> >> >>>> >> > toURL returns http://localhost:RANDOM_PORT/file-system/...
> >> >> >>>>Maybe
> >> >> >>>> >> that's
> >> >> >>>> >> > fine?
> >> >> >>>> >> >
> >> >> >>>> >> >
> >> >> >>>> >> > I don't think it's weird that an app will need to support
> >> >> >>>>WKWebView on
> >> >> >>>> >> some
> >> >> >>>> >> > OS versions, and UIWebView on others. That's already the
> case
> >> >>to
> >> >> >>>> >>support
> >> >> >>>> >> > iOS 7.
> >> >> >>>> >> >
> >> >> >>>> >> >
> >> >> >>>> >> >
> >> >> >>>> >> > On Wed, Oct 29, 2014 at 6:22 PM, Shazron <
> shazron@gmail.com>
> >> >> >>>>wrote:
> >> >> >>>> >> >
> >> >> >>>> >> > > This does not preclude using the file url API function I
> >> >> >>>>suppose.
> >> >> >>>> >> Here's
> >> >> >>>> >> > a
> >> >> >>>> >> > > flowchart on how I think it would work:
> >> >> >>>> >>http://i.imgur.com/zq4zreN.png
> >> >> >>>> >> > >
> >> >> >>>> >> > >
> >> >> >>>> >> > > On Wed, Oct 29, 2014 at 2:48 PM, Tommy Williams
> >> >> >>>><tommy@devgeeks.org
> >> >> >>>> >
> >> >> >>>> >> > > wrote:
> >> >> >>>> >> > >
> >> >> >>>> >> > > > This whole thing reeks of sadness and pain.
> >> >> >>>> >> > > >
> >> >> >>>> >> > > > The security implications of this will have to be
> >> >>considered
> >> >> >>>>very
> >> >> >>>> >> > > > carefully.
> >> >> >>>> >> > > > On 29 Oct 2014 16:40, "Shazron" <sh...@apache.org>
> >> >>wrote:
> >> >> >>>> >> > > >
> >> >> >>>> >> > > > > ## What We Know So Far
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > 1. Because of the file:// url loading bug, we
> couldn't
> >> >> >>>>support
> >> >> >>>> >>the
> >> >> >>>> >> > > > > WKWebView in the iOS 8 GM release. It has since been
> >> >>fixed,
> >> >> >>>>for
> >> >> >>>> >> > release
> >> >> >>>> >> > > > > post iOS 8.1 (not sure when), through a new WKWebView
> >> >>API
> >> >> >>>> >>function
> >> >> >>>> >> (
> >> >> >>>> >> > > > > http://trac.webkit.org/changeset/174029/trunk)
> >> >> >>>> >> > > > > 2. The alternative is embedding a local web server
> and
> >> >> >>>>serving
> >> >> >>>> >> assets
> >> >> >>>> >> > > > from
> >> >> >>>> >> > > > > that
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > ## Abandon file:// url Loading API Method
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > My proposal is, we abandon the local file:// url
> >> loading
> >> >> >>>>method
> >> >> >>>> >>in
> >> >> >>>> >> > (1)
> >> >> >>>> >> > > > > above, since it will create problems with support.
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > For example, if we support the new local file url
> >> >>loading
> >> >> >>>>API
> >> >> >>>> >> > function
> >> >> >>>> >> > > in
> >> >> >>>> >> > > > > iOS 8.2.0 (speculated) -- and a user is on 8.0.2,
> what
> >> >> >>>>then?
> >> >> >>>>You
> >> >> >>>> >> > would
> >> >> >>>> >> > > > not
> >> >> >>>> >> > > > > have WKWebView support for that user, and you would
> use
> >> >> >>>> >>UIWebView
> >> >> >>>> >> > > > instead.
> >> >> >>>> >> > > > > This will just be confusing, and leads to problems.
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > With the embedded local web server method, you can
> >> >>support
> >> >> >>>> >>**any**
> >> >> >>>> >> > > > version
> >> >> >>>> >> > > > > of iOS 8.x.
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > ## Embrace Embedded Local Web Server Method
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > I have a Cordova plugin that implements this, and it
> >> >>should
> >> >> >>>>work
> >> >> >>>> >> with
> >> >> >>>> >> > > > > cordova-ios 3.7.0:
> >> >> >>>> >> > > > > https://github.com/shazron/CordovaLocalWebServer
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > It dynamically updates the <access> tag value when it
> >> >> >>>>loads,
> >> >> >>>> >> > overriding
> >> >> >>>> >> > > > it
> >> >> >>>> >> > > > > to the actual location and port. Since it is a
> plugin,
> >> >>it
> >> >> >>>>can be
> >> >> >>>> >> > > > swappable
> >> >> >>>> >> > > > > (for whatever reason).
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > It does not solve the problem where any backgrounded
> >> app
> >> >> >>>>can
> >> >> >>>> >>access
> >> >> >>>> >> > our
> >> >> >>>> >> > > > > local web server.
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > ## Future Steps
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > This plugin is already working in cordova-ios 3.7.0
> >> >> >>>> >>(un-released,
> >> >> >>>> >> up
> >> >> >>>> >> > > next
> >> >> >>>> >> > > > > for vote release).
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > The wkwebview branch:
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > 1. Needs be rebased
> >> >> >>>> >> > > > > 2. Needs to be re-tested
> >> >> >>>> >> > > > > 3. issues in CB-7043 that relate to the wkwebview
> have
> >> >>to
> >> >> >>>>be
> >> >> >>>> >> resolved
> >> >> >>>> >> > > > > 4. branch presented for review to other committers
> >> >> >>>> >> > > > > 5. resolve any comments and issues from (4)
> >> >> >>>> >> > > > > 6. wkwebview branch integrated into master
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > I will work on these items next after getting
> >> >>cordova-ios
> >> >> >>>>3.7.0
> >> >> >>>> >> out.
> >> >> >>>> >> > > Any
> >> >> >>>> >> > > > > help is welcome.
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > ## Migration Issues
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > If you are migrating to WKWebView from UIWebView, you
> >> >>will
> >> >> >>>>lose
> >> >> >>>> >> some
> >> >> >>>> >> > > > > functionality.
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > > > 1. No more whitelist feature (NSURLProtocol is not
> >> >> >>>>supported
> >> >> >>>>in
> >> >> >>>> >> > > > WKWebView)
> >> >> >>>> >> > > > > 2. Your XmlHttpRequest calls now need to be CORS
> >> >>compliant
> >> >> >>>> >>(this is
> >> >> >>>> >> > > still
> >> >> >>>> >> > > > > true if loaded through a file:// url)
> >> >> >>>> >> > > > > 3. HTML5 offline application cache is not available
> in
> >> >> >>>> >>WKWebView (
> >> >> >>>> >> > > > > https://devforums.apple.com/message/1060452)
> >> >> >>>> >> > > > >
> >> >> >>>> >> > > >
> >> >> >>>> >> > >
> >> >> >>>> >> >
> >> >> >>>> >>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >>---------------------------------------------------------------------
> >> >> >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> >> >>>> For additional commands, e-mail: dev-help@cordova.apache.org
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >>---------------------------------------------------------------------
> >> >> >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> >> >>>> For additional commands, e-mail: dev-help@cordova.apache.org
> >> >> >>>>
> >> >> >>>>
> >> >> >>
> >> >> >
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> >> For additional commands, e-mail: dev-help@cordova.apache.org
> >> >>
> >>
> >>
> >
>
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
There have been major changes to the `wkwebview` branch of `cordova-ios`.
The `WKWebView` functionality has been moved to a plugin in the
`cordova-plugins` repo.
So, for now you can do:
cordova create wkwvtest test.project wkwvtest
cd wkwvtest
cordova platform add ios@wkwebview --usegit
cordova plugin add
https://github.com/apache/cordova-plugins.git#master:wkwebview-engine
Modify the root `config.xml` and edit this value to:
<content src="http://localhost:0" />
Then:
cordova emulate
You might get a build error, this is a `plugman` bug that doesn't install
`WebKit.framework` properly even though it is defined in plugin.xml. You
might have to do a:
open -a Xcode platforms/ios
...and add the framework manually.
On Thu, Nov 6, 2014 at 11:15 AM, Shazron <sh...@gmail.com> wrote:
> Thanks Tony - I'll look at that PR when I have some time.
>
> Yesterday I did some major work to isolate the webviews into plugins
> (CDVWKWebViewEngine, CDVUIWebViewEngine). This way we can reduce the risk
> by extracting the WKWebView items into a plugin, and the core has no
> dependency on WebKit.framework anymore, plus speedy (well, speedier)
> updates if it needs updating. The CDVUIWebViewEngine will remain in the
> core as the default engine. I'm still working on this, but it already works
> currently. I'm abstracting things out more, and removing code from the
> CDVViewController which has become unwieldy.
>
> Swapping out engines would use the preference:
> <preference name="CordovaWebViewEngine" value="CDVWKWebViewEngine" />
>
> Any new web engine needs to implement the new CDVWebViewEngineProtocol
> protocol, and installed as a plugin.
>
> On Mon, Nov 3, 2014 at 6:55 PM, Homer, Tony <to...@intel.com> wrote:
>
>> I have already forked it and made the changes in a topic branch.
>> I was originally thinking that I would make 2 topic branches: 1 for
>> localhost-only and 1 for auth tokens.
>> However, after I finished the first set of changes I realized that the
>> second set would be dependent on the first.
>> I’ll submit a pull request tomorrow for you to look at - I’ll be happy to
>> redo it as multiple branches if that makes sense.
>>
>> I got a little sidetracked with local web server plugin, but I’ve also
>> forked cordova-ios and made a topic branch from wkwebview.
>> I'll start working on some of the changes I proposed earlier in this
>> thread tomorrow (for plugins like camera that return file:// urls, etc.).
>>
>> Tony
>>
>> On 11/3/14, 7:23 PM, "Shazron" <sh...@gmail.com> wrote:
>>
>> >Thanks Tony for all the investigation. Please do fork the local web
>> server
>> >plugin and put all your work in topic branches for eventual pull requests
>> >to the main repo.
>> >
>> >This is precisely why the local web server is a plugin, and not in the
>> >core. I don't profess to be a security expert, and we can update this
>> >plugin to cover most of the security cases or someone else can provide
>> >their better plugin. I don't think this needs to be bulletproof, not that
>> >we can entirely be (has there ever been a Security Update by Apple that
>> >*didn't* include a WebKit vulnerability?)
>> >
>> >I'd like to get the cordova-ios/wkwebview branch back into the mainline
>> as
>> >soon as possible, but under an experimental flag (--experimental ?) for
>> >bin/create. This will choose a new template that has WebKit.framework in
>> >it, which will also define a macro to conditionally compile the new bits
>> >in
>> >(I haven't added the macros yet in the topic branch).
>> >
>> >
>> >
>> >
>> >On Mon, Nov 3, 2014 at 7:27 AM, Homer, Tony <to...@intel.com>
>> wrote:
>> >
>> >> I spent a lot of time thinking about ways to avoid replay attacks for
>> >>the
>> >> local web server plugin this weekend.
>> >>
>> >> Specifically, I felt like there should be a way to take advantage of
>> the
>> >> fact that the client and the server are running in the same process.
>> >> I thought this might enable some kind of sideband (non-http)
>> >> authentication possibility.
>> >> The 2 possibilities I was most interested in, but eventually concluded
>> >>are
>> >> not practical were:
>> >> 1. unique token per http request - not practical because there is no
>> per
>> >> http request event available
>> >> 2. a whitelist of “remote” ports - not practical because there is no
>> >> simple way to get a list of ports in use by WKWebView
>> >>
>> >> After going down this rathole and coming up empty, I reconsidered the
>> >> original problem and came to the following conclusions.
>> >> 1. restricting requests to localhost-only limits “attacks” to
>> >>backgrounded
>> >> apps
>> >> 2. including a token in the requests will prevent backgrounded apps
>> from
>> >> being able to successfully make unwanted requests
>> >> 3. the token is vulnerable to network analysis, but that cannot be done
>> >>on
>> >> device
>> >>
>> >> Therefore, vulnerability is limited to the case where the there is
>> >> (1) a “hostile" app installed on device and running in the background
>> >>and
>> >> (2) the user’s device is connected to a wi-fi network where an attacker
>> >>is
>> >> able to perform network analysis to capture the token.
>> >> In this case, the attacker could just inspect the HTTP traffic instead
>> >>of
>> >> capturing the token and sending it to their backgrounded app.
>> >> In other words, it seems that replay attacks are possible but not
>> >>useful.
>> >> If we care about the “hostile wifi network” case, we need something
>> like
>> >> SSL.
>> >>
>> >> On 11/1/14, 4:28 PM, "Homer, Tony" <to...@intel.com> wrote:
>> >>
>> >> >I started looking at how to make the camera plugin be able to work in
>> >> >WKWebView.
>> >> >Before, I had mentioned intercepting resource requests as a way to fix
>> >>the
>> >> >file:// requests.
>> >> >However, WKWebView does not offer a way to intercept resource requests
>> >>so
>> >> >that won’t work.
>> >> >:/
>> >> >
>> >> >Andrew had suggested introducing some proxy paths as a way to deal
>> with
>> >> >the path problems, which seems fine.
>> >> >On the other hand, the request handlers could just inspect the path in
>> >>the
>> >> >request and do the right thing - are the proxy paths needed?
>> >> >I think implicit in those comments was a suggestion that the affected
>> >> >plugins such as camera could return URLs using those paths.
>> >> >The thing about changing camera and file plugins to support localhost
>> >>that
>> >> >bothers me, is that now those core plugins effectively support a
>> >>non-core
>> >> >plugin.
>> >> >Also, other (on-cordova) plugins that depend on file protocol will be
>> >> >incompatible with the local web server wkwebview solution (unless they
>> >> >make changes to support it).
>> >> >
>> >> >I wonder if it would be better to handle this in CDVPluginResult?
>> >> >A hook could be added to initWithStatus and exposed to plugins.
>> >> >Then the SALocalWebServer plugin can use the hook to inspect the
>> >>message
>> >> >and fix it, if it is a file:// URL.
>> >> >So, for example, when camera calls CDVPluginResult
>> >> >resultWithStatus:messageAsString and passes in a file URL,
>> >>SALocalServer
>> >> >can get a chance to inspect and modify the result – changing it to an
>> >> >http:localhost URL. It could simply replace the file protocol with
>> >> >http://localhost:port, then the handler could decode the path before
>> >> >building the response.
>> >> >This is ugly, but it would prevent the need to change the camera and
>> >>file
>> >> >and should allow other non-cordova plugins that depend on file:// URLs
>> >>to
>> >> >work.
>> >> >
>> >> >
>> >> >Tony
>> >> >
>> >> >On 10/31/14, 2:03 PM, "Homer, Tony" <to...@intel.com> wrote:
>> >> >
>> >> >>I started with cookies in my POC, but I was concerned about replay
>> >> >>attacks.
>> >> >>I couldn’t think of a way to avoid replay vulnerability with cookies
>> >> >>(without SSL), so I was going to switch to the side channel approach
>> I
>> >> >>tried to describe. Do you think replay vulnerability is irrelevant?
>> >>I’m
>> >> >>not a security guy, so I wasn’t sure if it mattered or not. That’s
>> >> >>actually one of the things I was hoping to get feedback about.
>> >> >>
>> >> >>I guess I don’t follow how CORS relates to the camera plugin, does it
>> >>use
>> >> >>XHR? Maybe you can elaborate?
>> >> >>I expect I’ll see it when I try the camera plugin from WKWebView,
>> just
>> >> >>didn’t get around to it yet.
>> >> >>The only thing that jumps out at me is that you get a file:// url
>> >>back -
>> >> >>we could change that.
>> >> >>Or maybe intercept file:// requests in the plugin? If it’s just a
>> >>path
>> >> >>problem, maybe we could intercept the request, fix the path, then
>> >>respond
>> >> >>with the right thing...
>> >> >>
>> >> >>Tony
>> >> >>
>> >> >>On 10/31/14, 1:19 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
>> >> >>
>> >> >>>Unless you're having the server proxy requests to remote sites, I
>> >>don't
>> >> >>>think CORS headers are necessary.
>> >> >>>
>> >> >>>Tony - awesome stuff! absolutely doing it right. More
>> >>technical-focused
>> >> >>>discussion the better :). Using cookies seems the best way to me
>> >>since
>> >> >>>that
>> >> >>>covers all requests. Adding headers works only for XHRs.
>> >> >>>
>> >> >>>On Fri, Oct 31, 2014 at 12:12 PM, Kirk Shoop (MS OPEN TECH) <
>> >> >>>Kirk.Shoop@microsoft.com> wrote:
>> >> >>>
>> >> >>>> Yes, the handler should be able to add CORS headers to its
>> >>responses
>> >> >>>>that
>> >> >>>> will enable requests from any origin.
>> >> >>>>
>> >> >>>> For instance adding 'Access-Control-Allow-Origin: *' would allow
>> >>any
>> >> >>>> origin to make a request from the local server.
>> >> >>>>
>> >> http://www.w3.org/TR/cors/#access-control-allow-origin-response-header
>> >> >>>>
>> >> >>>> Similarly Access-Control-Allow-Methods and
>> >> >>>>Access-Control-Allow-Headers
>> >> >>>> could be used to define valid requests.
>> >> >>>>
>> >> >>>> Kirk
>> >> >>>>
>> >> >>>> Developer
>> >> >>>> Microsoft Open Technologies, Inc.
>> >> >>>>
>> >> >>>> -----Original Message-----
>> >> >>>> From: Homer, Tony [mailto:tony.homer@intel.com]
>> >> >>>> Sent: Friday, October 31, 2014 8:40 AM
>> >> >>>> To: dev@cordova.apache.org
>> >> >>>> Subject: Re: [iOS 8] WKWebView moving forward
>> >> >>>>
>> >> >>>> Last night I added a handler to the Local Web Server plugin that
>> >> >>>>returns
>> >> >>>> 403 for non-localhost requests.
>> >> >>>> The handler also has a prototype token system to restrict requests
>> >>to
>> >> >>>>the
>> >> >>>> app, but I need to change the approach a bit.
>> >> >>>> Currently I set a cookie and the handler just checks for the
>> cookie
>> >> >>>>and
>> >> >>>> returns 403 if it is missing.
>> >> >>>> This is susceptible to replay attacks from backgrounded apps - not
>> >> >>>>sure
>> >> >>>>if
>> >> >>>> that is important or not.
>> >> >>>>
>> >> >>>> I¹m going to investigate adding a map to the plugin, then add an
>> >>entry
>> >> >>>>for
>> >> >>>> every request.
>> >> >>>> The entry will be a hash of the request and a random number.
>> >> >>>>
>> >> >>>> I¹ll have to wire up support for overriding url loads so that I
>> can
>> >> >>>>add
>> >> >>>> the header with the random number to the request.
>> >> >>>> Then the request handler will look the entry up in the map and
>> >>remove
>> >> >>>>it -
>> >> >>>> this should eliminate re-playability.
>> >> >>>>
>> >> >>>> I¹m not sure about the CORS issue with camera pluginŠ I¹ll be
>> >>curious
>> >> >>>>to
>> >> >>>> test it - maybe it could be addressed by modifying the response in
>> >>the
>> >> >>>> GCDWebServer handler?
>> >> >>>>
>> >> >>>> Tony
>> >> >>>>
>> >> >>>> P.S. This is my first attempt participating in discussion on the
>> >>list
>> >> >>>>-
>> >> >>>> let me know if I¹m doing it wrong!
>> >> >>>> Am I wasting my time investigating this? Should I just leave it
>> >> >>>>Shazron?
>> >> >>>>
>> >> >>>> On 10/30/14, 9:52 PM, "Andrew Grieve" <ag...@chromium.org>
>> wrote:
>> >> >>>>
>> >> >>>> >On Thu, Oct 30, 2014 at 5:05 PM, Shazron <sh...@gmail.com>
>> >>wrote:
>> >> >>>> >
>> >> >>>> >> The port conflict situation has been solved with the latest
>> >>version
>> >> >>>> >>of the plugin. Passing in a port of "0" will choose a random
>> >>port.
>> >> >>>> >>More details in the plugin's README.md
>> >> >>>> >>
>> >> >>>> >Awesome! Why even allow a non-random port?
>> >> >>>> >Also learned today that in chrome, webcrypto API is disabled for
>> >>http
>> >> >>>> >origins, but enabled for https. Not sure if this is true for
>> >>Safari
>> >> >>>>as
>> >> >>>> >well, but certainly this change will be a can of worms!
>> >> >>>> >
>> >> >>>> >
>> >> >>>> >>
>> >> >>>> >> Ouch - didn't think about Camera plugin and File plugin impact.
>> >> >>>>That
>> >> >>>> >>proxy thing might work, as long as there are no folder name
>> >> >>>> >>collisions.
>> >> >>>> >>
>> >> >>>> >Prefixing all resources into a fake top-level directory will
>> >> >>>>eliminate
>> >> >>>> >the folder name collision problem I think.
>> >> >>>> >
>> >> >>>> >
>> >> >>>> >>
>> >> >>>> >> My point regarding mixing WKWebView and UIWebView on iOS 8 is,
>> >>if
>> >> >>>>you
>> >> >>>> >>have a user on iOS 8.x, you want all users on that iOS version
>> >>to
>> >> >>>> >>have the same experience, and for bug reporting purposes.
>> >> >>>> >
>> >> >>>> >
>> >> >>>> >> On Wed, Oct 29, 2014 at 5:11 PM, Andrew Grieve
>> >> >>>><ag...@chromium.org>
>> >> >>>> >> wrote:
>> >> >>>> >>
>> >> >>>> >> > We could restrict access to the webserver by stuffing a
>> cookie
>> >> >>>>into
>> >> >>>> >>the
>> >> >>>> >> > webview with an access token, then have the server just 500
>> on
>> >> >>>>any
>> >> >>>> >> request
>> >> >>>> >> > missing the cookie. We should also be able to restrict
>> >>external
>> >> >>>> >>requests
>> >> >>>> >> > just by listening on 127.0.0.1 instead of 0.0.0.0 (doesn't
>> >>look
>> >> >>>> >> > like GCDWebServer supports this, but we can hack it in).
>> >> >>>> >> >
>> >> >>>> >> > The problem of port conflicts is annoying though. Maybe we
>> try
>> >> >>>>random
>> >> >>>> >> ports
>> >> >>>> >> > until one works? Is there any need to use the same port for
>> >> >>>>multiple
>> >> >>>> >> runs?
>> >> >>>> >> >
>> >> >>>> >> > The CORS thing is sad, because it also means things like
>> >>Camera
>> >> >>>>plugin
>> >> >>>> >> will
>> >> >>>> >> > be broken (can't use resulting URL in <img>).
>> >> >>>> >> >
>> >> >>>> >> > Although we might just do (this is different than the current
>> >> >>>>mapping
>> >> >>>> >>in
>> >> >>>> >> > the plugin):
>> >> >>>> >> > http://localhost:RANDOM_PORT/www
>> >> >>>> >> > http://localhost:RANDOM_PORT/asset-library
>> >> >>>> >> > http://localhost:RANDOM_PORT/file-system
>> >> >>>> >> >
>> >> >>>> >> > to proxy the three locations.
>> >> >>>> >> >
>> >> >>>> >> > This also means we can't use FileEntry.toURL() and have it
>> >>work,
>> >> >>>> >>unless
>> >> >>>> >> > toURL returns http://localhost:RANDOM_PORT/file-system/...
>> >> >>>>Maybe
>> >> >>>> >> that's
>> >> >>>> >> > fine?
>> >> >>>> >> >
>> >> >>>> >> >
>> >> >>>> >> > I don't think it's weird that an app will need to support
>> >> >>>>WKWebView on
>> >> >>>> >> some
>> >> >>>> >> > OS versions, and UIWebView on others. That's already the case
>> >>to
>> >> >>>> >>support
>> >> >>>> >> > iOS 7.
>> >> >>>> >> >
>> >> >>>> >> >
>> >> >>>> >> >
>> >> >>>> >> > On Wed, Oct 29, 2014 at 6:22 PM, Shazron <sh...@gmail.com>
>> >> >>>>wrote:
>> >> >>>> >> >
>> >> >>>> >> > > This does not preclude using the file url API function I
>> >> >>>>suppose.
>> >> >>>> >> Here's
>> >> >>>> >> > a
>> >> >>>> >> > > flowchart on how I think it would work:
>> >> >>>> >>http://i.imgur.com/zq4zreN.png
>> >> >>>> >> > >
>> >> >>>> >> > >
>> >> >>>> >> > > On Wed, Oct 29, 2014 at 2:48 PM, Tommy Williams
>> >> >>>><tommy@devgeeks.org
>> >> >>>> >
>> >> >>>> >> > > wrote:
>> >> >>>> >> > >
>> >> >>>> >> > > > This whole thing reeks of sadness and pain.
>> >> >>>> >> > > >
>> >> >>>> >> > > > The security implications of this will have to be
>> >>considered
>> >> >>>>very
>> >> >>>> >> > > > carefully.
>> >> >>>> >> > > > On 29 Oct 2014 16:40, "Shazron" <sh...@apache.org>
>> >>wrote:
>> >> >>>> >> > > >
>> >> >>>> >> > > > > ## What We Know So Far
>> >> >>>> >> > > > >
>> >> >>>> >> > > > > 1. Because of the file:// url loading bug, we couldn't
>> >> >>>>support
>> >> >>>> >>the
>> >> >>>> >> > > > > WKWebView in the iOS 8 GM release. It has since been
>> >>fixed,
>> >> >>>>for
>> >> >>>> >> > release
>> >> >>>> >> > > > > post iOS 8.1 (not sure when), through a new WKWebView
>> >>API
>> >> >>>> >>function
>> >> >>>> >> (
>> >> >>>> >> > > > > http://trac.webkit.org/changeset/174029/trunk)
>> >> >>>> >> > > > > 2. The alternative is embedding a local web server and
>> >> >>>>serving
>> >> >>>> >> assets
>> >> >>>> >> > > > from
>> >> >>>> >> > > > > that
>> >> >>>> >> > > > >
>> >> >>>> >> > > > > ## Abandon file:// url Loading API Method
>> >> >>>> >> > > > >
>> >> >>>> >> > > > > My proposal is, we abandon the local file:// url
>> loading
>> >> >>>>method
>> >> >>>> >>in
>> >> >>>> >> > (1)
>> >> >>>> >> > > > > above, since it will create problems with support.
>> >> >>>> >> > > > >
>> >> >>>> >> > > > > For example, if we support the new local file url
>> >>loading
>> >> >>>>API
>> >> >>>> >> > function
>> >> >>>> >> > > in
>> >> >>>> >> > > > > iOS 8.2.0 (speculated) -- and a user is on 8.0.2, what
>> >> >>>>then?
>> >> >>>>You
>> >> >>>> >> > would
>> >> >>>> >> > > > not
>> >> >>>> >> > > > > have WKWebView support for that user, and you would use
>> >> >>>> >>UIWebView
>> >> >>>> >> > > > instead.
>> >> >>>> >> > > > > This will just be confusing, and leads to problems.
>> >> >>>> >> > > > >
>> >> >>>> >> > > > > With the embedded local web server method, you can
>> >>support
>> >> >>>> >>**any**
>> >> >>>> >> > > > version
>> >> >>>> >> > > > > of iOS 8.x.
>> >> >>>> >> > > > >
>> >> >>>> >> > > > > ## Embrace Embedded Local Web Server Method
>> >> >>>> >> > > > >
>> >> >>>> >> > > > > I have a Cordova plugin that implements this, and it
>> >>should
>> >> >>>>work
>> >> >>>> >> with
>> >> >>>> >> > > > > cordova-ios 3.7.0:
>> >> >>>> >> > > > > https://github.com/shazron/CordovaLocalWebServer
>> >> >>>> >> > > > >
>> >> >>>> >> > > > > It dynamically updates the <access> tag value when it
>> >> >>>>loads,
>> >> >>>> >> > overriding
>> >> >>>> >> > > > it
>> >> >>>> >> > > > > to the actual location and port. Since it is a plugin,
>> >>it
>> >> >>>>can be
>> >> >>>> >> > > > swappable
>> >> >>>> >> > > > > (for whatever reason).
>> >> >>>> >> > > > >
>> >> >>>> >> > > > > It does not solve the problem where any backgrounded
>> app
>> >> >>>>can
>> >> >>>> >>access
>> >> >>>> >> > our
>> >> >>>> >> > > > > local web server.
>> >> >>>> >> > > > >
>> >> >>>> >> > > > > ## Future Steps
>> >> >>>> >> > > > >
>> >> >>>> >> > > > > This plugin is already working in cordova-ios 3.7.0
>> >> >>>> >>(un-released,
>> >> >>>> >> up
>> >> >>>> >> > > next
>> >> >>>> >> > > > > for vote release).
>> >> >>>> >> > > > >
>> >> >>>> >> > > > > The wkwebview branch:
>> >> >>>> >> > > > >
>> >> >>>> >> > > > > 1. Needs be rebased
>> >> >>>> >> > > > > 2. Needs to be re-tested
>> >> >>>> >> > > > > 3. issues in CB-7043 that relate to the wkwebview have
>> >>to
>> >> >>>>be
>> >> >>>> >> resolved
>> >> >>>> >> > > > > 4. branch presented for review to other committers
>> >> >>>> >> > > > > 5. resolve any comments and issues from (4)
>> >> >>>> >> > > > > 6. wkwebview branch integrated into master
>> >> >>>> >> > > > >
>> >> >>>> >> > > > > I will work on these items next after getting
>> >>cordova-ios
>> >> >>>>3.7.0
>> >> >>>> >> out.
>> >> >>>> >> > > Any
>> >> >>>> >> > > > > help is welcome.
>> >> >>>> >> > > > >
>> >> >>>> >> > > > > ## Migration Issues
>> >> >>>> >> > > > >
>> >> >>>> >> > > > > If you are migrating to WKWebView from UIWebView, you
>> >>will
>> >> >>>>lose
>> >> >>>> >> some
>> >> >>>> >> > > > > functionality.
>> >> >>>> >> > > > >
>> >> >>>> >> > > > > 1. No more whitelist feature (NSURLProtocol is not
>> >> >>>>supported
>> >> >>>>in
>> >> >>>> >> > > > WKWebView)
>> >> >>>> >> > > > > 2. Your XmlHttpRequest calls now need to be CORS
>> >>compliant
>> >> >>>> >>(this is
>> >> >>>> >> > > still
>> >> >>>> >> > > > > true if loaded through a file:// url)
>> >> >>>> >> > > > > 3. HTML5 offline application cache is not available in
>> >> >>>> >>WKWebView (
>> >> >>>> >> > > > > https://devforums.apple.com/message/1060452)
>> >> >>>> >> > > > >
>> >> >>>> >> > > >
>> >> >>>> >> > >
>> >> >>>> >> >
>> >> >>>> >>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >>---------------------------------------------------------------------
>> >> >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> >> >>>> For additional commands, e-mail: dev-help@cordova.apache.org
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >>---------------------------------------------------------------------
>> >> >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> >> >>>> For additional commands, e-mail: dev-help@cordova.apache.org
>> >> >>>>
>> >> >>>>
>> >> >>
>> >> >
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> >> For additional commands, e-mail: dev-help@cordova.apache.org
>> >>
>>
>>
>
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
Thanks Tony - I'll look at that PR when I have some time.
Yesterday I did some major work to isolate the webviews into plugins
(CDVWKWebViewEngine, CDVUIWebViewEngine). This way we can reduce the risk
by extracting the WKWebView items into a plugin, and the core has no
dependency on WebKit.framework anymore, plus speedy (well, speedier)
updates if it needs updating. The CDVUIWebViewEngine will remain in the
core as the default engine. I'm still working on this, but it already works
currently. I'm abstracting things out more, and removing code from the
CDVViewController which has become unwieldy.
Swapping out engines would use the preference:
<preference name="CordovaWebViewEngine" value="CDVWKWebViewEngine" />
Any new web engine needs to implement the new CDVWebViewEngineProtocol
protocol, and installed as a plugin.
On Mon, Nov 3, 2014 at 6:55 PM, Homer, Tony <to...@intel.com> wrote:
> I have already forked it and made the changes in a topic branch.
> I was originally thinking that I would make 2 topic branches: 1 for
> localhost-only and 1 for auth tokens.
> However, after I finished the first set of changes I realized that the
> second set would be dependent on the first.
> I’ll submit a pull request tomorrow for you to look at - I’ll be happy to
> redo it as multiple branches if that makes sense.
>
> I got a little sidetracked with local web server plugin, but I’ve also
> forked cordova-ios and made a topic branch from wkwebview.
> I'll start working on some of the changes I proposed earlier in this
> thread tomorrow (for plugins like camera that return file:// urls, etc.).
>
> Tony
>
> On 11/3/14, 7:23 PM, "Shazron" <sh...@gmail.com> wrote:
>
> >Thanks Tony for all the investigation. Please do fork the local web server
> >plugin and put all your work in topic branches for eventual pull requests
> >to the main repo.
> >
> >This is precisely why the local web server is a plugin, and not in the
> >core. I don't profess to be a security expert, and we can update this
> >plugin to cover most of the security cases or someone else can provide
> >their better plugin. I don't think this needs to be bulletproof, not that
> >we can entirely be (has there ever been a Security Update by Apple that
> >*didn't* include a WebKit vulnerability?)
> >
> >I'd like to get the cordova-ios/wkwebview branch back into the mainline as
> >soon as possible, but under an experimental flag (--experimental ?) for
> >bin/create. This will choose a new template that has WebKit.framework in
> >it, which will also define a macro to conditionally compile the new bits
> >in
> >(I haven't added the macros yet in the topic branch).
> >
> >
> >
> >
> >On Mon, Nov 3, 2014 at 7:27 AM, Homer, Tony <to...@intel.com> wrote:
> >
> >> I spent a lot of time thinking about ways to avoid replay attacks for
> >>the
> >> local web server plugin this weekend.
> >>
> >> Specifically, I felt like there should be a way to take advantage of the
> >> fact that the client and the server are running in the same process.
> >> I thought this might enable some kind of sideband (non-http)
> >> authentication possibility.
> >> The 2 possibilities I was most interested in, but eventually concluded
> >>are
> >> not practical were:
> >> 1. unique token per http request - not practical because there is no per
> >> http request event available
> >> 2. a whitelist of “remote” ports - not practical because there is no
> >> simple way to get a list of ports in use by WKWebView
> >>
> >> After going down this rathole and coming up empty, I reconsidered the
> >> original problem and came to the following conclusions.
> >> 1. restricting requests to localhost-only limits “attacks” to
> >>backgrounded
> >> apps
> >> 2. including a token in the requests will prevent backgrounded apps from
> >> being able to successfully make unwanted requests
> >> 3. the token is vulnerable to network analysis, but that cannot be done
> >>on
> >> device
> >>
> >> Therefore, vulnerability is limited to the case where the there is
> >> (1) a “hostile" app installed on device and running in the background
> >>and
> >> (2) the user’s device is connected to a wi-fi network where an attacker
> >>is
> >> able to perform network analysis to capture the token.
> >> In this case, the attacker could just inspect the HTTP traffic instead
> >>of
> >> capturing the token and sending it to their backgrounded app.
> >> In other words, it seems that replay attacks are possible but not
> >>useful.
> >> If we care about the “hostile wifi network” case, we need something like
> >> SSL.
> >>
> >> On 11/1/14, 4:28 PM, "Homer, Tony" <to...@intel.com> wrote:
> >>
> >> >I started looking at how to make the camera plugin be able to work in
> >> >WKWebView.
> >> >Before, I had mentioned intercepting resource requests as a way to fix
> >>the
> >> >file:// requests.
> >> >However, WKWebView does not offer a way to intercept resource requests
> >>so
> >> >that won’t work.
> >> >:/
> >> >
> >> >Andrew had suggested introducing some proxy paths as a way to deal with
> >> >the path problems, which seems fine.
> >> >On the other hand, the request handlers could just inspect the path in
> >>the
> >> >request and do the right thing - are the proxy paths needed?
> >> >I think implicit in those comments was a suggestion that the affected
> >> >plugins such as camera could return URLs using those paths.
> >> >The thing about changing camera and file plugins to support localhost
> >>that
> >> >bothers me, is that now those core plugins effectively support a
> >>non-core
> >> >plugin.
> >> >Also, other (on-cordova) plugins that depend on file protocol will be
> >> >incompatible with the local web server wkwebview solution (unless they
> >> >make changes to support it).
> >> >
> >> >I wonder if it would be better to handle this in CDVPluginResult?
> >> >A hook could be added to initWithStatus and exposed to plugins.
> >> >Then the SALocalWebServer plugin can use the hook to inspect the
> >>message
> >> >and fix it, if it is a file:// URL.
> >> >So, for example, when camera calls CDVPluginResult
> >> >resultWithStatus:messageAsString and passes in a file URL,
> >>SALocalServer
> >> >can get a chance to inspect and modify the result – changing it to an
> >> >http:localhost URL. It could simply replace the file protocol with
> >> >http://localhost:port, then the handler could decode the path before
> >> >building the response.
> >> >This is ugly, but it would prevent the need to change the camera and
> >>file
> >> >and should allow other non-cordova plugins that depend on file:// URLs
> >>to
> >> >work.
> >> >
> >> >
> >> >Tony
> >> >
> >> >On 10/31/14, 2:03 PM, "Homer, Tony" <to...@intel.com> wrote:
> >> >
> >> >>I started with cookies in my POC, but I was concerned about replay
> >> >>attacks.
> >> >>I couldn’t think of a way to avoid replay vulnerability with cookies
> >> >>(without SSL), so I was going to switch to the side channel approach I
> >> >>tried to describe. Do you think replay vulnerability is irrelevant?
> >>I’m
> >> >>not a security guy, so I wasn’t sure if it mattered or not. That’s
> >> >>actually one of the things I was hoping to get feedback about.
> >> >>
> >> >>I guess I don’t follow how CORS relates to the camera plugin, does it
> >>use
> >> >>XHR? Maybe you can elaborate?
> >> >>I expect I’ll see it when I try the camera plugin from WKWebView, just
> >> >>didn’t get around to it yet.
> >> >>The only thing that jumps out at me is that you get a file:// url
> >>back -
> >> >>we could change that.
> >> >>Or maybe intercept file:// requests in the plugin? If it’s just a
> >>path
> >> >>problem, maybe we could intercept the request, fix the path, then
> >>respond
> >> >>with the right thing...
> >> >>
> >> >>Tony
> >> >>
> >> >>On 10/31/14, 1:19 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
> >> >>
> >> >>>Unless you're having the server proxy requests to remote sites, I
> >>don't
> >> >>>think CORS headers are necessary.
> >> >>>
> >> >>>Tony - awesome stuff! absolutely doing it right. More
> >>technical-focused
> >> >>>discussion the better :). Using cookies seems the best way to me
> >>since
> >> >>>that
> >> >>>covers all requests. Adding headers works only for XHRs.
> >> >>>
> >> >>>On Fri, Oct 31, 2014 at 12:12 PM, Kirk Shoop (MS OPEN TECH) <
> >> >>>Kirk.Shoop@microsoft.com> wrote:
> >> >>>
> >> >>>> Yes, the handler should be able to add CORS headers to its
> >>responses
> >> >>>>that
> >> >>>> will enable requests from any origin.
> >> >>>>
> >> >>>> For instance adding 'Access-Control-Allow-Origin: *' would allow
> >>any
> >> >>>> origin to make a request from the local server.
> >> >>>>
> >> http://www.w3.org/TR/cors/#access-control-allow-origin-response-header
> >> >>>>
> >> >>>> Similarly Access-Control-Allow-Methods and
> >> >>>>Access-Control-Allow-Headers
> >> >>>> could be used to define valid requests.
> >> >>>>
> >> >>>> Kirk
> >> >>>>
> >> >>>> Developer
> >> >>>> Microsoft Open Technologies, Inc.
> >> >>>>
> >> >>>> -----Original Message-----
> >> >>>> From: Homer, Tony [mailto:tony.homer@intel.com]
> >> >>>> Sent: Friday, October 31, 2014 8:40 AM
> >> >>>> To: dev@cordova.apache.org
> >> >>>> Subject: Re: [iOS 8] WKWebView moving forward
> >> >>>>
> >> >>>> Last night I added a handler to the Local Web Server plugin that
> >> >>>>returns
> >> >>>> 403 for non-localhost requests.
> >> >>>> The handler also has a prototype token system to restrict requests
> >>to
> >> >>>>the
> >> >>>> app, but I need to change the approach a bit.
> >> >>>> Currently I set a cookie and the handler just checks for the cookie
> >> >>>>and
> >> >>>> returns 403 if it is missing.
> >> >>>> This is susceptible to replay attacks from backgrounded apps - not
> >> >>>>sure
> >> >>>>if
> >> >>>> that is important or not.
> >> >>>>
> >> >>>> I¹m going to investigate adding a map to the plugin, then add an
> >>entry
> >> >>>>for
> >> >>>> every request.
> >> >>>> The entry will be a hash of the request and a random number.
> >> >>>>
> >> >>>> I¹ll have to wire up support for overriding url loads so that I can
> >> >>>>add
> >> >>>> the header with the random number to the request.
> >> >>>> Then the request handler will look the entry up in the map and
> >>remove
> >> >>>>it -
> >> >>>> this should eliminate re-playability.
> >> >>>>
> >> >>>> I¹m not sure about the CORS issue with camera pluginŠ I¹ll be
> >>curious
> >> >>>>to
> >> >>>> test it - maybe it could be addressed by modifying the response in
> >>the
> >> >>>> GCDWebServer handler?
> >> >>>>
> >> >>>> Tony
> >> >>>>
> >> >>>> P.S. This is my first attempt participating in discussion on the
> >>list
> >> >>>>-
> >> >>>> let me know if I¹m doing it wrong!
> >> >>>> Am I wasting my time investigating this? Should I just leave it
> >> >>>>Shazron?
> >> >>>>
> >> >>>> On 10/30/14, 9:52 PM, "Andrew Grieve" <ag...@chromium.org>
> wrote:
> >> >>>>
> >> >>>> >On Thu, Oct 30, 2014 at 5:05 PM, Shazron <sh...@gmail.com>
> >>wrote:
> >> >>>> >
> >> >>>> >> The port conflict situation has been solved with the latest
> >>version
> >> >>>> >>of the plugin. Passing in a port of "0" will choose a random
> >>port.
> >> >>>> >>More details in the plugin's README.md
> >> >>>> >>
> >> >>>> >Awesome! Why even allow a non-random port?
> >> >>>> >Also learned today that in chrome, webcrypto API is disabled for
> >>http
> >> >>>> >origins, but enabled for https. Not sure if this is true for
> >>Safari
> >> >>>>as
> >> >>>> >well, but certainly this change will be a can of worms!
> >> >>>> >
> >> >>>> >
> >> >>>> >>
> >> >>>> >> Ouch - didn't think about Camera plugin and File plugin impact.
> >> >>>>That
> >> >>>> >>proxy thing might work, as long as there are no folder name
> >> >>>> >>collisions.
> >> >>>> >>
> >> >>>> >Prefixing all resources into a fake top-level directory will
> >> >>>>eliminate
> >> >>>> >the folder name collision problem I think.
> >> >>>> >
> >> >>>> >
> >> >>>> >>
> >> >>>> >> My point regarding mixing WKWebView and UIWebView on iOS 8 is,
> >>if
> >> >>>>you
> >> >>>> >>have a user on iOS 8.x, you want all users on that iOS version
> >>to
> >> >>>> >>have the same experience, and for bug reporting purposes.
> >> >>>> >
> >> >>>> >
> >> >>>> >> On Wed, Oct 29, 2014 at 5:11 PM, Andrew Grieve
> >> >>>><ag...@chromium.org>
> >> >>>> >> wrote:
> >> >>>> >>
> >> >>>> >> > We could restrict access to the webserver by stuffing a cookie
> >> >>>>into
> >> >>>> >>the
> >> >>>> >> > webview with an access token, then have the server just 500 on
> >> >>>>any
> >> >>>> >> request
> >> >>>> >> > missing the cookie. We should also be able to restrict
> >>external
> >> >>>> >>requests
> >> >>>> >> > just by listening on 127.0.0.1 instead of 0.0.0.0 (doesn't
> >>look
> >> >>>> >> > like GCDWebServer supports this, but we can hack it in).
> >> >>>> >> >
> >> >>>> >> > The problem of port conflicts is annoying though. Maybe we try
> >> >>>>random
> >> >>>> >> ports
> >> >>>> >> > until one works? Is there any need to use the same port for
> >> >>>>multiple
> >> >>>> >> runs?
> >> >>>> >> >
> >> >>>> >> > The CORS thing is sad, because it also means things like
> >>Camera
> >> >>>>plugin
> >> >>>> >> will
> >> >>>> >> > be broken (can't use resulting URL in <img>).
> >> >>>> >> >
> >> >>>> >> > Although we might just do (this is different than the current
> >> >>>>mapping
> >> >>>> >>in
> >> >>>> >> > the plugin):
> >> >>>> >> > http://localhost:RANDOM_PORT/www
> >> >>>> >> > http://localhost:RANDOM_PORT/asset-library
> >> >>>> >> > http://localhost:RANDOM_PORT/file-system
> >> >>>> >> >
> >> >>>> >> > to proxy the three locations.
> >> >>>> >> >
> >> >>>> >> > This also means we can't use FileEntry.toURL() and have it
> >>work,
> >> >>>> >>unless
> >> >>>> >> > toURL returns http://localhost:RANDOM_PORT/file-system/...
> >> >>>>Maybe
> >> >>>> >> that's
> >> >>>> >> > fine?
> >> >>>> >> >
> >> >>>> >> >
> >> >>>> >> > I don't think it's weird that an app will need to support
> >> >>>>WKWebView on
> >> >>>> >> some
> >> >>>> >> > OS versions, and UIWebView on others. That's already the case
> >>to
> >> >>>> >>support
> >> >>>> >> > iOS 7.
> >> >>>> >> >
> >> >>>> >> >
> >> >>>> >> >
> >> >>>> >> > On Wed, Oct 29, 2014 at 6:22 PM, Shazron <sh...@gmail.com>
> >> >>>>wrote:
> >> >>>> >> >
> >> >>>> >> > > This does not preclude using the file url API function I
> >> >>>>suppose.
> >> >>>> >> Here's
> >> >>>> >> > a
> >> >>>> >> > > flowchart on how I think it would work:
> >> >>>> >>http://i.imgur.com/zq4zreN.png
> >> >>>> >> > >
> >> >>>> >> > >
> >> >>>> >> > > On Wed, Oct 29, 2014 at 2:48 PM, Tommy Williams
> >> >>>><tommy@devgeeks.org
> >> >>>> >
> >> >>>> >> > > wrote:
> >> >>>> >> > >
> >> >>>> >> > > > This whole thing reeks of sadness and pain.
> >> >>>> >> > > >
> >> >>>> >> > > > The security implications of this will have to be
> >>considered
> >> >>>>very
> >> >>>> >> > > > carefully.
> >> >>>> >> > > > On 29 Oct 2014 16:40, "Shazron" <sh...@apache.org>
> >>wrote:
> >> >>>> >> > > >
> >> >>>> >> > > > > ## What We Know So Far
> >> >>>> >> > > > >
> >> >>>> >> > > > > 1. Because of the file:// url loading bug, we couldn't
> >> >>>>support
> >> >>>> >>the
> >> >>>> >> > > > > WKWebView in the iOS 8 GM release. It has since been
> >>fixed,
> >> >>>>for
> >> >>>> >> > release
> >> >>>> >> > > > > post iOS 8.1 (not sure when), through a new WKWebView
> >>API
> >> >>>> >>function
> >> >>>> >> (
> >> >>>> >> > > > > http://trac.webkit.org/changeset/174029/trunk)
> >> >>>> >> > > > > 2. The alternative is embedding a local web server and
> >> >>>>serving
> >> >>>> >> assets
> >> >>>> >> > > > from
> >> >>>> >> > > > > that
> >> >>>> >> > > > >
> >> >>>> >> > > > > ## Abandon file:// url Loading API Method
> >> >>>> >> > > > >
> >> >>>> >> > > > > My proposal is, we abandon the local file:// url loading
> >> >>>>method
> >> >>>> >>in
> >> >>>> >> > (1)
> >> >>>> >> > > > > above, since it will create problems with support.
> >> >>>> >> > > > >
> >> >>>> >> > > > > For example, if we support the new local file url
> >>loading
> >> >>>>API
> >> >>>> >> > function
> >> >>>> >> > > in
> >> >>>> >> > > > > iOS 8.2.0 (speculated) -- and a user is on 8.0.2, what
> >> >>>>then?
> >> >>>>You
> >> >>>> >> > would
> >> >>>> >> > > > not
> >> >>>> >> > > > > have WKWebView support for that user, and you would use
> >> >>>> >>UIWebView
> >> >>>> >> > > > instead.
> >> >>>> >> > > > > This will just be confusing, and leads to problems.
> >> >>>> >> > > > >
> >> >>>> >> > > > > With the embedded local web server method, you can
> >>support
> >> >>>> >>**any**
> >> >>>> >> > > > version
> >> >>>> >> > > > > of iOS 8.x.
> >> >>>> >> > > > >
> >> >>>> >> > > > > ## Embrace Embedded Local Web Server Method
> >> >>>> >> > > > >
> >> >>>> >> > > > > I have a Cordova plugin that implements this, and it
> >>should
> >> >>>>work
> >> >>>> >> with
> >> >>>> >> > > > > cordova-ios 3.7.0:
> >> >>>> >> > > > > https://github.com/shazron/CordovaLocalWebServer
> >> >>>> >> > > > >
> >> >>>> >> > > > > It dynamically updates the <access> tag value when it
> >> >>>>loads,
> >> >>>> >> > overriding
> >> >>>> >> > > > it
> >> >>>> >> > > > > to the actual location and port. Since it is a plugin,
> >>it
> >> >>>>can be
> >> >>>> >> > > > swappable
> >> >>>> >> > > > > (for whatever reason).
> >> >>>> >> > > > >
> >> >>>> >> > > > > It does not solve the problem where any backgrounded app
> >> >>>>can
> >> >>>> >>access
> >> >>>> >> > our
> >> >>>> >> > > > > local web server.
> >> >>>> >> > > > >
> >> >>>> >> > > > > ## Future Steps
> >> >>>> >> > > > >
> >> >>>> >> > > > > This plugin is already working in cordova-ios 3.7.0
> >> >>>> >>(un-released,
> >> >>>> >> up
> >> >>>> >> > > next
> >> >>>> >> > > > > for vote release).
> >> >>>> >> > > > >
> >> >>>> >> > > > > The wkwebview branch:
> >> >>>> >> > > > >
> >> >>>> >> > > > > 1. Needs be rebased
> >> >>>> >> > > > > 2. Needs to be re-tested
> >> >>>> >> > > > > 3. issues in CB-7043 that relate to the wkwebview have
> >>to
> >> >>>>be
> >> >>>> >> resolved
> >> >>>> >> > > > > 4. branch presented for review to other committers
> >> >>>> >> > > > > 5. resolve any comments and issues from (4)
> >> >>>> >> > > > > 6. wkwebview branch integrated into master
> >> >>>> >> > > > >
> >> >>>> >> > > > > I will work on these items next after getting
> >>cordova-ios
> >> >>>>3.7.0
> >> >>>> >> out.
> >> >>>> >> > > Any
> >> >>>> >> > > > > help is welcome.
> >> >>>> >> > > > >
> >> >>>> >> > > > > ## Migration Issues
> >> >>>> >> > > > >
> >> >>>> >> > > > > If you are migrating to WKWebView from UIWebView, you
> >>will
> >> >>>>lose
> >> >>>> >> some
> >> >>>> >> > > > > functionality.
> >> >>>> >> > > > >
> >> >>>> >> > > > > 1. No more whitelist feature (NSURLProtocol is not
> >> >>>>supported
> >> >>>>in
> >> >>>> >> > > > WKWebView)
> >> >>>> >> > > > > 2. Your XmlHttpRequest calls now need to be CORS
> >>compliant
> >> >>>> >>(this is
> >> >>>> >> > > still
> >> >>>> >> > > > > true if loaded through a file:// url)
> >> >>>> >> > > > > 3. HTML5 offline application cache is not available in
> >> >>>> >>WKWebView (
> >> >>>> >> > > > > https://devforums.apple.com/message/1060452)
> >> >>>> >> > > > >
> >> >>>> >> > > >
> >> >>>> >> > >
> >> >>>> >> >
> >> >>>> >>
> >> >>>>
> >> >>>>
> >> >>>>
> >>---------------------------------------------------------------------
> >> >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> >>>> For additional commands, e-mail: dev-help@cordova.apache.org
> >> >>>>
> >> >>>>
> >> >>>>
> >>---------------------------------------------------------------------
> >> >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> >>>> For additional commands, e-mail: dev-help@cordova.apache.org
> >> >>>>
> >> >>>>
> >> >>
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> For additional commands, e-mail: dev-help@cordova.apache.org
> >>
>
>
Re: [iOS 8] WKWebView moving forward
Posted by "Homer, Tony" <to...@intel.com>.
I have already forked it and made the changes in a topic branch.
I was originally thinking that I would make 2 topic branches: 1 for
localhost-only and 1 for auth tokens.
However, after I finished the first set of changes I realized that the
second set would be dependent on the first.
I’ll submit a pull request tomorrow for you to look at - I’ll be happy to
redo it as multiple branches if that makes sense.
I got a little sidetracked with local web server plugin, but I’ve also
forked cordova-ios and made a topic branch from wkwebview.
I'll start working on some of the changes I proposed earlier in this
thread tomorrow (for plugins like camera that return file:// urls, etc.).
Tony
On 11/3/14, 7:23 PM, "Shazron" <sh...@gmail.com> wrote:
>Thanks Tony for all the investigation. Please do fork the local web server
>plugin and put all your work in topic branches for eventual pull requests
>to the main repo.
>
>This is precisely why the local web server is a plugin, and not in the
>core. I don't profess to be a security expert, and we can update this
>plugin to cover most of the security cases or someone else can provide
>their better plugin. I don't think this needs to be bulletproof, not that
>we can entirely be (has there ever been a Security Update by Apple that
>*didn't* include a WebKit vulnerability?)
>
>I'd like to get the cordova-ios/wkwebview branch back into the mainline as
>soon as possible, but under an experimental flag (--experimental ?) for
>bin/create. This will choose a new template that has WebKit.framework in
>it, which will also define a macro to conditionally compile the new bits
>in
>(I haven't added the macros yet in the topic branch).
>
>
>
>
>On Mon, Nov 3, 2014 at 7:27 AM, Homer, Tony <to...@intel.com> wrote:
>
>> I spent a lot of time thinking about ways to avoid replay attacks for
>>the
>> local web server plugin this weekend.
>>
>> Specifically, I felt like there should be a way to take advantage of the
>> fact that the client and the server are running in the same process.
>> I thought this might enable some kind of sideband (non-http)
>> authentication possibility.
>> The 2 possibilities I was most interested in, but eventually concluded
>>are
>> not practical were:
>> 1. unique token per http request - not practical because there is no per
>> http request event available
>> 2. a whitelist of “remote” ports - not practical because there is no
>> simple way to get a list of ports in use by WKWebView
>>
>> After going down this rathole and coming up empty, I reconsidered the
>> original problem and came to the following conclusions.
>> 1. restricting requests to localhost-only limits “attacks” to
>>backgrounded
>> apps
>> 2. including a token in the requests will prevent backgrounded apps from
>> being able to successfully make unwanted requests
>> 3. the token is vulnerable to network analysis, but that cannot be done
>>on
>> device
>>
>> Therefore, vulnerability is limited to the case where the there is
>> (1) a “hostile" app installed on device and running in the background
>>and
>> (2) the user’s device is connected to a wi-fi network where an attacker
>>is
>> able to perform network analysis to capture the token.
>> In this case, the attacker could just inspect the HTTP traffic instead
>>of
>> capturing the token and sending it to their backgrounded app.
>> In other words, it seems that replay attacks are possible but not
>>useful.
>> If we care about the “hostile wifi network” case, we need something like
>> SSL.
>>
>> On 11/1/14, 4:28 PM, "Homer, Tony" <to...@intel.com> wrote:
>>
>> >I started looking at how to make the camera plugin be able to work in
>> >WKWebView.
>> >Before, I had mentioned intercepting resource requests as a way to fix
>>the
>> >file:// requests.
>> >However, WKWebView does not offer a way to intercept resource requests
>>so
>> >that won’t work.
>> >:/
>> >
>> >Andrew had suggested introducing some proxy paths as a way to deal with
>> >the path problems, which seems fine.
>> >On the other hand, the request handlers could just inspect the path in
>>the
>> >request and do the right thing - are the proxy paths needed?
>> >I think implicit in those comments was a suggestion that the affected
>> >plugins such as camera could return URLs using those paths.
>> >The thing about changing camera and file plugins to support localhost
>>that
>> >bothers me, is that now those core plugins effectively support a
>>non-core
>> >plugin.
>> >Also, other (on-cordova) plugins that depend on file protocol will be
>> >incompatible with the local web server wkwebview solution (unless they
>> >make changes to support it).
>> >
>> >I wonder if it would be better to handle this in CDVPluginResult?
>> >A hook could be added to initWithStatus and exposed to plugins.
>> >Then the SALocalWebServer plugin can use the hook to inspect the
>>message
>> >and fix it, if it is a file:// URL.
>> >So, for example, when camera calls CDVPluginResult
>> >resultWithStatus:messageAsString and passes in a file URL,
>>SALocalServer
>> >can get a chance to inspect and modify the result – changing it to an
>> >http:localhost URL. It could simply replace the file protocol with
>> >http://localhost:port, then the handler could decode the path before
>> >building the response.
>> >This is ugly, but it would prevent the need to change the camera and
>>file
>> >and should allow other non-cordova plugins that depend on file:// URLs
>>to
>> >work.
>> >
>> >
>> >Tony
>> >
>> >On 10/31/14, 2:03 PM, "Homer, Tony" <to...@intel.com> wrote:
>> >
>> >>I started with cookies in my POC, but I was concerned about replay
>> >>attacks.
>> >>I couldn’t think of a way to avoid replay vulnerability with cookies
>> >>(without SSL), so I was going to switch to the side channel approach I
>> >>tried to describe. Do you think replay vulnerability is irrelevant?
>>I’m
>> >>not a security guy, so I wasn’t sure if it mattered or not. That’s
>> >>actually one of the things I was hoping to get feedback about.
>> >>
>> >>I guess I don’t follow how CORS relates to the camera plugin, does it
>>use
>> >>XHR? Maybe you can elaborate?
>> >>I expect I’ll see it when I try the camera plugin from WKWebView, just
>> >>didn’t get around to it yet.
>> >>The only thing that jumps out at me is that you get a file:// url
>>back -
>> >>we could change that.
>> >>Or maybe intercept file:// requests in the plugin? If it’s just a
>>path
>> >>problem, maybe we could intercept the request, fix the path, then
>>respond
>> >>with the right thing...
>> >>
>> >>Tony
>> >>
>> >>On 10/31/14, 1:19 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
>> >>
>> >>>Unless you're having the server proxy requests to remote sites, I
>>don't
>> >>>think CORS headers are necessary.
>> >>>
>> >>>Tony - awesome stuff! absolutely doing it right. More
>>technical-focused
>> >>>discussion the better :). Using cookies seems the best way to me
>>since
>> >>>that
>> >>>covers all requests. Adding headers works only for XHRs.
>> >>>
>> >>>On Fri, Oct 31, 2014 at 12:12 PM, Kirk Shoop (MS OPEN TECH) <
>> >>>Kirk.Shoop@microsoft.com> wrote:
>> >>>
>> >>>> Yes, the handler should be able to add CORS headers to its
>>responses
>> >>>>that
>> >>>> will enable requests from any origin.
>> >>>>
>> >>>> For instance adding 'Access-Control-Allow-Origin: *' would allow
>>any
>> >>>> origin to make a request from the local server.
>> >>>>
>> http://www.w3.org/TR/cors/#access-control-allow-origin-response-header
>> >>>>
>> >>>> Similarly Access-Control-Allow-Methods and
>> >>>>Access-Control-Allow-Headers
>> >>>> could be used to define valid requests.
>> >>>>
>> >>>> Kirk
>> >>>>
>> >>>> Developer
>> >>>> Microsoft Open Technologies, Inc.
>> >>>>
>> >>>> -----Original Message-----
>> >>>> From: Homer, Tony [mailto:tony.homer@intel.com]
>> >>>> Sent: Friday, October 31, 2014 8:40 AM
>> >>>> To: dev@cordova.apache.org
>> >>>> Subject: Re: [iOS 8] WKWebView moving forward
>> >>>>
>> >>>> Last night I added a handler to the Local Web Server plugin that
>> >>>>returns
>> >>>> 403 for non-localhost requests.
>> >>>> The handler also has a prototype token system to restrict requests
>>to
>> >>>>the
>> >>>> app, but I need to change the approach a bit.
>> >>>> Currently I set a cookie and the handler just checks for the cookie
>> >>>>and
>> >>>> returns 403 if it is missing.
>> >>>> This is susceptible to replay attacks from backgrounded apps - not
>> >>>>sure
>> >>>>if
>> >>>> that is important or not.
>> >>>>
>> >>>> I¹m going to investigate adding a map to the plugin, then add an
>>entry
>> >>>>for
>> >>>> every request.
>> >>>> The entry will be a hash of the request and a random number.
>> >>>>
>> >>>> I¹ll have to wire up support for overriding url loads so that I can
>> >>>>add
>> >>>> the header with the random number to the request.
>> >>>> Then the request handler will look the entry up in the map and
>>remove
>> >>>>it -
>> >>>> this should eliminate re-playability.
>> >>>>
>> >>>> I¹m not sure about the CORS issue with camera pluginŠ I¹ll be
>>curious
>> >>>>to
>> >>>> test it - maybe it could be addressed by modifying the response in
>>the
>> >>>> GCDWebServer handler?
>> >>>>
>> >>>> Tony
>> >>>>
>> >>>> P.S. This is my first attempt participating in discussion on the
>>list
>> >>>>-
>> >>>> let me know if I¹m doing it wrong!
>> >>>> Am I wasting my time investigating this? Should I just leave it
>> >>>>Shazron?
>> >>>>
>> >>>> On 10/30/14, 9:52 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
>> >>>>
>> >>>> >On Thu, Oct 30, 2014 at 5:05 PM, Shazron <sh...@gmail.com>
>>wrote:
>> >>>> >
>> >>>> >> The port conflict situation has been solved with the latest
>>version
>> >>>> >>of the plugin. Passing in a port of "0" will choose a random
>>port.
>> >>>> >>More details in the plugin's README.md
>> >>>> >>
>> >>>> >Awesome! Why even allow a non-random port?
>> >>>> >Also learned today that in chrome, webcrypto API is disabled for
>>http
>> >>>> >origins, but enabled for https. Not sure if this is true for
>>Safari
>> >>>>as
>> >>>> >well, but certainly this change will be a can of worms!
>> >>>> >
>> >>>> >
>> >>>> >>
>> >>>> >> Ouch - didn't think about Camera plugin and File plugin impact.
>> >>>>That
>> >>>> >>proxy thing might work, as long as there are no folder name
>> >>>> >>collisions.
>> >>>> >>
>> >>>> >Prefixing all resources into a fake top-level directory will
>> >>>>eliminate
>> >>>> >the folder name collision problem I think.
>> >>>> >
>> >>>> >
>> >>>> >>
>> >>>> >> My point regarding mixing WKWebView and UIWebView on iOS 8 is,
>>if
>> >>>>you
>> >>>> >>have a user on iOS 8.x, you want all users on that iOS version
>>to
>> >>>> >>have the same experience, and for bug reporting purposes.
>> >>>> >
>> >>>> >
>> >>>> >> On Wed, Oct 29, 2014 at 5:11 PM, Andrew Grieve
>> >>>><ag...@chromium.org>
>> >>>> >> wrote:
>> >>>> >>
>> >>>> >> > We could restrict access to the webserver by stuffing a cookie
>> >>>>into
>> >>>> >>the
>> >>>> >> > webview with an access token, then have the server just 500 on
>> >>>>any
>> >>>> >> request
>> >>>> >> > missing the cookie. We should also be able to restrict
>>external
>> >>>> >>requests
>> >>>> >> > just by listening on 127.0.0.1 instead of 0.0.0.0 (doesn't
>>look
>> >>>> >> > like GCDWebServer supports this, but we can hack it in).
>> >>>> >> >
>> >>>> >> > The problem of port conflicts is annoying though. Maybe we try
>> >>>>random
>> >>>> >> ports
>> >>>> >> > until one works? Is there any need to use the same port for
>> >>>>multiple
>> >>>> >> runs?
>> >>>> >> >
>> >>>> >> > The CORS thing is sad, because it also means things like
>>Camera
>> >>>>plugin
>> >>>> >> will
>> >>>> >> > be broken (can't use resulting URL in <img>).
>> >>>> >> >
>> >>>> >> > Although we might just do (this is different than the current
>> >>>>mapping
>> >>>> >>in
>> >>>> >> > the plugin):
>> >>>> >> > http://localhost:RANDOM_PORT/www
>> >>>> >> > http://localhost:RANDOM_PORT/asset-library
>> >>>> >> > http://localhost:RANDOM_PORT/file-system
>> >>>> >> >
>> >>>> >> > to proxy the three locations.
>> >>>> >> >
>> >>>> >> > This also means we can't use FileEntry.toURL() and have it
>>work,
>> >>>> >>unless
>> >>>> >> > toURL returns http://localhost:RANDOM_PORT/file-system/...
>> >>>>Maybe
>> >>>> >> that's
>> >>>> >> > fine?
>> >>>> >> >
>> >>>> >> >
>> >>>> >> > I don't think it's weird that an app will need to support
>> >>>>WKWebView on
>> >>>> >> some
>> >>>> >> > OS versions, and UIWebView on others. That's already the case
>>to
>> >>>> >>support
>> >>>> >> > iOS 7.
>> >>>> >> >
>> >>>> >> >
>> >>>> >> >
>> >>>> >> > On Wed, Oct 29, 2014 at 6:22 PM, Shazron <sh...@gmail.com>
>> >>>>wrote:
>> >>>> >> >
>> >>>> >> > > This does not preclude using the file url API function I
>> >>>>suppose.
>> >>>> >> Here's
>> >>>> >> > a
>> >>>> >> > > flowchart on how I think it would work:
>> >>>> >>http://i.imgur.com/zq4zreN.png
>> >>>> >> > >
>> >>>> >> > >
>> >>>> >> > > On Wed, Oct 29, 2014 at 2:48 PM, Tommy Williams
>> >>>><tommy@devgeeks.org
>> >>>> >
>> >>>> >> > > wrote:
>> >>>> >> > >
>> >>>> >> > > > This whole thing reeks of sadness and pain.
>> >>>> >> > > >
>> >>>> >> > > > The security implications of this will have to be
>>considered
>> >>>>very
>> >>>> >> > > > carefully.
>> >>>> >> > > > On 29 Oct 2014 16:40, "Shazron" <sh...@apache.org>
>>wrote:
>> >>>> >> > > >
>> >>>> >> > > > > ## What We Know So Far
>> >>>> >> > > > >
>> >>>> >> > > > > 1. Because of the file:// url loading bug, we couldn't
>> >>>>support
>> >>>> >>the
>> >>>> >> > > > > WKWebView in the iOS 8 GM release. It has since been
>>fixed,
>> >>>>for
>> >>>> >> > release
>> >>>> >> > > > > post iOS 8.1 (not sure when), through a new WKWebView
>>API
>> >>>> >>function
>> >>>> >> (
>> >>>> >> > > > > http://trac.webkit.org/changeset/174029/trunk)
>> >>>> >> > > > > 2. The alternative is embedding a local web server and
>> >>>>serving
>> >>>> >> assets
>> >>>> >> > > > from
>> >>>> >> > > > > that
>> >>>> >> > > > >
>> >>>> >> > > > > ## Abandon file:// url Loading API Method
>> >>>> >> > > > >
>> >>>> >> > > > > My proposal is, we abandon the local file:// url loading
>> >>>>method
>> >>>> >>in
>> >>>> >> > (1)
>> >>>> >> > > > > above, since it will create problems with support.
>> >>>> >> > > > >
>> >>>> >> > > > > For example, if we support the new local file url
>>loading
>> >>>>API
>> >>>> >> > function
>> >>>> >> > > in
>> >>>> >> > > > > iOS 8.2.0 (speculated) -- and a user is on 8.0.2, what
>> >>>>then?
>> >>>>You
>> >>>> >> > would
>> >>>> >> > > > not
>> >>>> >> > > > > have WKWebView support for that user, and you would use
>> >>>> >>UIWebView
>> >>>> >> > > > instead.
>> >>>> >> > > > > This will just be confusing, and leads to problems.
>> >>>> >> > > > >
>> >>>> >> > > > > With the embedded local web server method, you can
>>support
>> >>>> >>**any**
>> >>>> >> > > > version
>> >>>> >> > > > > of iOS 8.x.
>> >>>> >> > > > >
>> >>>> >> > > > > ## Embrace Embedded Local Web Server Method
>> >>>> >> > > > >
>> >>>> >> > > > > I have a Cordova plugin that implements this, and it
>>should
>> >>>>work
>> >>>> >> with
>> >>>> >> > > > > cordova-ios 3.7.0:
>> >>>> >> > > > > https://github.com/shazron/CordovaLocalWebServer
>> >>>> >> > > > >
>> >>>> >> > > > > It dynamically updates the <access> tag value when it
>> >>>>loads,
>> >>>> >> > overriding
>> >>>> >> > > > it
>> >>>> >> > > > > to the actual location and port. Since it is a plugin,
>>it
>> >>>>can be
>> >>>> >> > > > swappable
>> >>>> >> > > > > (for whatever reason).
>> >>>> >> > > > >
>> >>>> >> > > > > It does not solve the problem where any backgrounded app
>> >>>>can
>> >>>> >>access
>> >>>> >> > our
>> >>>> >> > > > > local web server.
>> >>>> >> > > > >
>> >>>> >> > > > > ## Future Steps
>> >>>> >> > > > >
>> >>>> >> > > > > This plugin is already working in cordova-ios 3.7.0
>> >>>> >>(un-released,
>> >>>> >> up
>> >>>> >> > > next
>> >>>> >> > > > > for vote release).
>> >>>> >> > > > >
>> >>>> >> > > > > The wkwebview branch:
>> >>>> >> > > > >
>> >>>> >> > > > > 1. Needs be rebased
>> >>>> >> > > > > 2. Needs to be re-tested
>> >>>> >> > > > > 3. issues in CB-7043 that relate to the wkwebview have
>>to
>> >>>>be
>> >>>> >> resolved
>> >>>> >> > > > > 4. branch presented for review to other committers
>> >>>> >> > > > > 5. resolve any comments and issues from (4)
>> >>>> >> > > > > 6. wkwebview branch integrated into master
>> >>>> >> > > > >
>> >>>> >> > > > > I will work on these items next after getting
>>cordova-ios
>> >>>>3.7.0
>> >>>> >> out.
>> >>>> >> > > Any
>> >>>> >> > > > > help is welcome.
>> >>>> >> > > > >
>> >>>> >> > > > > ## Migration Issues
>> >>>> >> > > > >
>> >>>> >> > > > > If you are migrating to WKWebView from UIWebView, you
>>will
>> >>>>lose
>> >>>> >> some
>> >>>> >> > > > > functionality.
>> >>>> >> > > > >
>> >>>> >> > > > > 1. No more whitelist feature (NSURLProtocol is not
>> >>>>supported
>> >>>>in
>> >>>> >> > > > WKWebView)
>> >>>> >> > > > > 2. Your XmlHttpRequest calls now need to be CORS
>>compliant
>> >>>> >>(this is
>> >>>> >> > > still
>> >>>> >> > > > > true if loaded through a file:// url)
>> >>>> >> > > > > 3. HTML5 offline application cache is not available in
>> >>>> >>WKWebView (
>> >>>> >> > > > > https://devforums.apple.com/message/1060452)
>> >>>> >> > > > >
>> >>>> >> > > >
>> >>>> >> > >
>> >>>> >> >
>> >>>> >>
>> >>>>
>> >>>>
>> >>>>
>>---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> >>>> For additional commands, e-mail: dev-help@cordova.apache.org
>> >>>>
>> >>>>
>> >>>>
>>---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> >>>> For additional commands, e-mail: dev-help@cordova.apache.org
>> >>>>
>> >>>>
>> >>
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>>
Re: [iOS 8] WKWebView moving forward
Posted by Shazron <sh...@gmail.com>.
Thanks Tony for all the investigation. Please do fork the local web server
plugin and put all your work in topic branches for eventual pull requests
to the main repo.
This is precisely why the local web server is a plugin, and not in the
core. I don't profess to be a security expert, and we can update this
plugin to cover most of the security cases or someone else can provide
their better plugin. I don't think this needs to be bulletproof, not that
we can entirely be (has there ever been a Security Update by Apple that
*didn't* include a WebKit vulnerability?)
I'd like to get the cordova-ios/wkwebview branch back into the mainline as
soon as possible, but under an experimental flag (--experimental ?) for
bin/create. This will choose a new template that has WebKit.framework in
it, which will also define a macro to conditionally compile the new bits in
(I haven't added the macros yet in the topic branch).
On Mon, Nov 3, 2014 at 7:27 AM, Homer, Tony <to...@intel.com> wrote:
> I spent a lot of time thinking about ways to avoid replay attacks for the
> local web server plugin this weekend.
>
> Specifically, I felt like there should be a way to take advantage of the
> fact that the client and the server are running in the same process.
> I thought this might enable some kind of sideband (non-http)
> authentication possibility.
> The 2 possibilities I was most interested in, but eventually concluded are
> not practical were:
> 1. unique token per http request - not practical because there is no per
> http request event available
> 2. a whitelist of “remote” ports - not practical because there is no
> simple way to get a list of ports in use by WKWebView
>
> After going down this rathole and coming up empty, I reconsidered the
> original problem and came to the following conclusions.
> 1. restricting requests to localhost-only limits “attacks” to backgrounded
> apps
> 2. including a token in the requests will prevent backgrounded apps from
> being able to successfully make unwanted requests
> 3. the token is vulnerable to network analysis, but that cannot be done on
> device
>
> Therefore, vulnerability is limited to the case where the there is
> (1) a “hostile" app installed on device and running in the background and
> (2) the user’s device is connected to a wi-fi network where an attacker is
> able to perform network analysis to capture the token.
> In this case, the attacker could just inspect the HTTP traffic instead of
> capturing the token and sending it to their backgrounded app.
> In other words, it seems that replay attacks are possible but not useful.
> If we care about the “hostile wifi network” case, we need something like
> SSL.
>
> On 11/1/14, 4:28 PM, "Homer, Tony" <to...@intel.com> wrote:
>
> >I started looking at how to make the camera plugin be able to work in
> >WKWebView.
> >Before, I had mentioned intercepting resource requests as a way to fix the
> >file:// requests.
> >However, WKWebView does not offer a way to intercept resource requests so
> >that won’t work.
> >:/
> >
> >Andrew had suggested introducing some proxy paths as a way to deal with
> >the path problems, which seems fine.
> >On the other hand, the request handlers could just inspect the path in the
> >request and do the right thing - are the proxy paths needed?
> >I think implicit in those comments was a suggestion that the affected
> >plugins such as camera could return URLs using those paths.
> >The thing about changing camera and file plugins to support localhost that
> >bothers me, is that now those core plugins effectively support a non-core
> >plugin.
> >Also, other (on-cordova) plugins that depend on file protocol will be
> >incompatible with the local web server wkwebview solution (unless they
> >make changes to support it).
> >
> >I wonder if it would be better to handle this in CDVPluginResult?
> >A hook could be added to initWithStatus and exposed to plugins.
> >Then the SALocalWebServer plugin can use the hook to inspect the message
> >and fix it, if it is a file:// URL.
> >So, for example, when camera calls CDVPluginResult
> >resultWithStatus:messageAsString and passes in a file URL, SALocalServer
> >can get a chance to inspect and modify the result – changing it to an
> >http:localhost URL. It could simply replace the file protocol with
> >http://localhost:port, then the handler could decode the path before
> >building the response.
> >This is ugly, but it would prevent the need to change the camera and file
> >and should allow other non-cordova plugins that depend on file:// URLs to
> >work.
> >
> >
> >Tony
> >
> >On 10/31/14, 2:03 PM, "Homer, Tony" <to...@intel.com> wrote:
> >
> >>I started with cookies in my POC, but I was concerned about replay
> >>attacks.
> >>I couldn’t think of a way to avoid replay vulnerability with cookies
> >>(without SSL), so I was going to switch to the side channel approach I
> >>tried to describe. Do you think replay vulnerability is irrelevant? I’m
> >>not a security guy, so I wasn’t sure if it mattered or not. That’s
> >>actually one of the things I was hoping to get feedback about.
> >>
> >>I guess I don’t follow how CORS relates to the camera plugin, does it use
> >>XHR? Maybe you can elaborate?
> >>I expect I’ll see it when I try the camera plugin from WKWebView, just
> >>didn’t get around to it yet.
> >>The only thing that jumps out at me is that you get a file:// url back -
> >>we could change that.
> >>Or maybe intercept file:// requests in the plugin? If it’s just a path
> >>problem, maybe we could intercept the request, fix the path, then respond
> >>with the right thing...
> >>
> >>Tony
> >>
> >>On 10/31/14, 1:19 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
> >>
> >>>Unless you're having the server proxy requests to remote sites, I don't
> >>>think CORS headers are necessary.
> >>>
> >>>Tony - awesome stuff! absolutely doing it right. More technical-focused
> >>>discussion the better :). Using cookies seems the best way to me since
> >>>that
> >>>covers all requests. Adding headers works only for XHRs.
> >>>
> >>>On Fri, Oct 31, 2014 at 12:12 PM, Kirk Shoop (MS OPEN TECH) <
> >>>Kirk.Shoop@microsoft.com> wrote:
> >>>
> >>>> Yes, the handler should be able to add CORS headers to its responses
> >>>>that
> >>>> will enable requests from any origin.
> >>>>
> >>>> For instance adding 'Access-Control-Allow-Origin: *' would allow any
> >>>> origin to make a request from the local server.
> >>>>
> http://www.w3.org/TR/cors/#access-control-allow-origin-response-header
> >>>>
> >>>> Similarly Access-Control-Allow-Methods and
> >>>>Access-Control-Allow-Headers
> >>>> could be used to define valid requests.
> >>>>
> >>>> Kirk
> >>>>
> >>>> Developer
> >>>> Microsoft Open Technologies, Inc.
> >>>>
> >>>> -----Original Message-----
> >>>> From: Homer, Tony [mailto:tony.homer@intel.com]
> >>>> Sent: Friday, October 31, 2014 8:40 AM
> >>>> To: dev@cordova.apache.org
> >>>> Subject: Re: [iOS 8] WKWebView moving forward
> >>>>
> >>>> Last night I added a handler to the Local Web Server plugin that
> >>>>returns
> >>>> 403 for non-localhost requests.
> >>>> The handler also has a prototype token system to restrict requests to
> >>>>the
> >>>> app, but I need to change the approach a bit.
> >>>> Currently I set a cookie and the handler just checks for the cookie
> >>>>and
> >>>> returns 403 if it is missing.
> >>>> This is susceptible to replay attacks from backgrounded apps - not
> >>>>sure
> >>>>if
> >>>> that is important or not.
> >>>>
> >>>> I¹m going to investigate adding a map to the plugin, then add an entry
> >>>>for
> >>>> every request.
> >>>> The entry will be a hash of the request and a random number.
> >>>>
> >>>> I¹ll have to wire up support for overriding url loads so that I can
> >>>>add
> >>>> the header with the random number to the request.
> >>>> Then the request handler will look the entry up in the map and remove
> >>>>it -
> >>>> this should eliminate re-playability.
> >>>>
> >>>> I¹m not sure about the CORS issue with camera pluginŠ I¹ll be curious
> >>>>to
> >>>> test it - maybe it could be addressed by modifying the response in the
> >>>> GCDWebServer handler?
> >>>>
> >>>> Tony
> >>>>
> >>>> P.S. This is my first attempt participating in discussion on the list
> >>>>-
> >>>> let me know if I¹m doing it wrong!
> >>>> Am I wasting my time investigating this? Should I just leave it
> >>>>Shazron?
> >>>>
> >>>> On 10/30/14, 9:52 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
> >>>>
> >>>> >On Thu, Oct 30, 2014 at 5:05 PM, Shazron <sh...@gmail.com> wrote:
> >>>> >
> >>>> >> The port conflict situation has been solved with the latest version
> >>>> >>of the plugin. Passing in a port of "0" will choose a random port.
> >>>> >>More details in the plugin's README.md
> >>>> >>
> >>>> >Awesome! Why even allow a non-random port?
> >>>> >Also learned today that in chrome, webcrypto API is disabled for http
> >>>> >origins, but enabled for https. Not sure if this is true for Safari
> >>>>as
> >>>> >well, but certainly this change will be a can of worms!
> >>>> >
> >>>> >
> >>>> >>
> >>>> >> Ouch - didn't think about Camera plugin and File plugin impact.
> >>>>That
> >>>> >>proxy thing might work, as long as there are no folder name
> >>>> >>collisions.
> >>>> >>
> >>>> >Prefixing all resources into a fake top-level directory will
> >>>>eliminate
> >>>> >the folder name collision problem I think.
> >>>> >
> >>>> >
> >>>> >>
> >>>> >> My point regarding mixing WKWebView and UIWebView on iOS 8 is, if
> >>>>you
> >>>> >>have a user on iOS 8.x, you want all users on that iOS version to
> >>>> >>have the same experience, and for bug reporting purposes.
> >>>> >
> >>>> >
> >>>> >> On Wed, Oct 29, 2014 at 5:11 PM, Andrew Grieve
> >>>><ag...@chromium.org>
> >>>> >> wrote:
> >>>> >>
> >>>> >> > We could restrict access to the webserver by stuffing a cookie
> >>>>into
> >>>> >>the
> >>>> >> > webview with an access token, then have the server just 500 on
> >>>>any
> >>>> >> request
> >>>> >> > missing the cookie. We should also be able to restrict external
> >>>> >>requests
> >>>> >> > just by listening on 127.0.0.1 instead of 0.0.0.0 (doesn't look
> >>>> >> > like GCDWebServer supports this, but we can hack it in).
> >>>> >> >
> >>>> >> > The problem of port conflicts is annoying though. Maybe we try
> >>>>random
> >>>> >> ports
> >>>> >> > until one works? Is there any need to use the same port for
> >>>>multiple
> >>>> >> runs?
> >>>> >> >
> >>>> >> > The CORS thing is sad, because it also means things like Camera
> >>>>plugin
> >>>> >> will
> >>>> >> > be broken (can't use resulting URL in <img>).
> >>>> >> >
> >>>> >> > Although we might just do (this is different than the current
> >>>>mapping
> >>>> >>in
> >>>> >> > the plugin):
> >>>> >> > http://localhost:RANDOM_PORT/www
> >>>> >> > http://localhost:RANDOM_PORT/asset-library
> >>>> >> > http://localhost:RANDOM_PORT/file-system
> >>>> >> >
> >>>> >> > to proxy the three locations.
> >>>> >> >
> >>>> >> > This also means we can't use FileEntry.toURL() and have it work,
> >>>> >>unless
> >>>> >> > toURL returns http://localhost:RANDOM_PORT/file-system/...
> >>>>Maybe
> >>>> >> that's
> >>>> >> > fine?
> >>>> >> >
> >>>> >> >
> >>>> >> > I don't think it's weird that an app will need to support
> >>>>WKWebView on
> >>>> >> some
> >>>> >> > OS versions, and UIWebView on others. That's already the case to
> >>>> >>support
> >>>> >> > iOS 7.
> >>>> >> >
> >>>> >> >
> >>>> >> >
> >>>> >> > On Wed, Oct 29, 2014 at 6:22 PM, Shazron <sh...@gmail.com>
> >>>>wrote:
> >>>> >> >
> >>>> >> > > This does not preclude using the file url API function I
> >>>>suppose.
> >>>> >> Here's
> >>>> >> > a
> >>>> >> > > flowchart on how I think it would work:
> >>>> >>http://i.imgur.com/zq4zreN.png
> >>>> >> > >
> >>>> >> > >
> >>>> >> > > On Wed, Oct 29, 2014 at 2:48 PM, Tommy Williams
> >>>><tommy@devgeeks.org
> >>>> >
> >>>> >> > > wrote:
> >>>> >> > >
> >>>> >> > > > This whole thing reeks of sadness and pain.
> >>>> >> > > >
> >>>> >> > > > The security implications of this will have to be considered
> >>>>very
> >>>> >> > > > carefully.
> >>>> >> > > > On 29 Oct 2014 16:40, "Shazron" <sh...@apache.org> wrote:
> >>>> >> > > >
> >>>> >> > > > > ## What We Know So Far
> >>>> >> > > > >
> >>>> >> > > > > 1. Because of the file:// url loading bug, we couldn't
> >>>>support
> >>>> >>the
> >>>> >> > > > > WKWebView in the iOS 8 GM release. It has since been fixed,
> >>>>for
> >>>> >> > release
> >>>> >> > > > > post iOS 8.1 (not sure when), through a new WKWebView API
> >>>> >>function
> >>>> >> (
> >>>> >> > > > > http://trac.webkit.org/changeset/174029/trunk)
> >>>> >> > > > > 2. The alternative is embedding a local web server and
> >>>>serving
> >>>> >> assets
> >>>> >> > > > from
> >>>> >> > > > > that
> >>>> >> > > > >
> >>>> >> > > > > ## Abandon file:// url Loading API Method
> >>>> >> > > > >
> >>>> >> > > > > My proposal is, we abandon the local file:// url loading
> >>>>method
> >>>> >>in
> >>>> >> > (1)
> >>>> >> > > > > above, since it will create problems with support.
> >>>> >> > > > >
> >>>> >> > > > > For example, if we support the new local file url loading
> >>>>API
> >>>> >> > function
> >>>> >> > > in
> >>>> >> > > > > iOS 8.2.0 (speculated) -- and a user is on 8.0.2, what
> >>>>then?
> >>>>You
> >>>> >> > would
> >>>> >> > > > not
> >>>> >> > > > > have WKWebView support for that user, and you would use
> >>>> >>UIWebView
> >>>> >> > > > instead.
> >>>> >> > > > > This will just be confusing, and leads to problems.
> >>>> >> > > > >
> >>>> >> > > > > With the embedded local web server method, you can support
> >>>> >>**any**
> >>>> >> > > > version
> >>>> >> > > > > of iOS 8.x.
> >>>> >> > > > >
> >>>> >> > > > > ## Embrace Embedded Local Web Server Method
> >>>> >> > > > >
> >>>> >> > > > > I have a Cordova plugin that implements this, and it should
> >>>>work
> >>>> >> with
> >>>> >> > > > > cordova-ios 3.7.0:
> >>>> >> > > > > https://github.com/shazron/CordovaLocalWebServer
> >>>> >> > > > >
> >>>> >> > > > > It dynamically updates the <access> tag value when it
> >>>>loads,
> >>>> >> > overriding
> >>>> >> > > > it
> >>>> >> > > > > to the actual location and port. Since it is a plugin, it
> >>>>can be
> >>>> >> > > > swappable
> >>>> >> > > > > (for whatever reason).
> >>>> >> > > > >
> >>>> >> > > > > It does not solve the problem where any backgrounded app
> >>>>can
> >>>> >>access
> >>>> >> > our
> >>>> >> > > > > local web server.
> >>>> >> > > > >
> >>>> >> > > > > ## Future Steps
> >>>> >> > > > >
> >>>> >> > > > > This plugin is already working in cordova-ios 3.7.0
> >>>> >>(un-released,
> >>>> >> up
> >>>> >> > > next
> >>>> >> > > > > for vote release).
> >>>> >> > > > >
> >>>> >> > > > > The wkwebview branch:
> >>>> >> > > > >
> >>>> >> > > > > 1. Needs be rebased
> >>>> >> > > > > 2. Needs to be re-tested
> >>>> >> > > > > 3. issues in CB-7043 that relate to the wkwebview have to
> >>>>be
> >>>> >> resolved
> >>>> >> > > > > 4. branch presented for review to other committers
> >>>> >> > > > > 5. resolve any comments and issues from (4)
> >>>> >> > > > > 6. wkwebview branch integrated into master
> >>>> >> > > > >
> >>>> >> > > > > I will work on these items next after getting cordova-ios
> >>>>3.7.0
> >>>> >> out.
> >>>> >> > > Any
> >>>> >> > > > > help is welcome.
> >>>> >> > > > >
> >>>> >> > > > > ## Migration Issues
> >>>> >> > > > >
> >>>> >> > > > > If you are migrating to WKWebView from UIWebView, you will
> >>>>lose
> >>>> >> some
> >>>> >> > > > > functionality.
> >>>> >> > > > >
> >>>> >> > > > > 1. No more whitelist feature (NSURLProtocol is not
> >>>>supported
> >>>>in
> >>>> >> > > > WKWebView)
> >>>> >> > > > > 2. Your XmlHttpRequest calls now need to be CORS compliant
> >>>> >>(this is
> >>>> >> > > still
> >>>> >> > > > > true if loaded through a file:// url)
> >>>> >> > > > > 3. HTML5 offline application cache is not available in
> >>>> >>WKWebView (
> >>>> >> > > > > https://devforums.apple.com/message/1060452)
> >>>> >> > > > >
> >>>> >> > > >
> >>>> >> > >
> >>>> >> >
> >>>> >>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >>>> For additional commands, e-mail: dev-help@cordova.apache.org
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >>>> For additional commands, e-mail: dev-help@cordova.apache.org
> >>>>
> >>>>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
Re: [iOS 8] WKWebView moving forward
Posted by Michal Mocny <mm...@chromium.org>.
Awesome analysis Tony, thanks for the efforts & the great summary.
On Mon, Nov 3, 2014 at 10:27 AM, Homer, Tony <to...@intel.com> wrote:
> I spent a lot of time thinking about ways to avoid replay attacks for the
> local web server plugin this weekend.
>
> Specifically, I felt like there should be a way to take advantage of the
> fact that the client and the server are running in the same process.
> I thought this might enable some kind of sideband (non-http)
> authentication possibility.
> The 2 possibilities I was most interested in, but eventually concluded are
> not practical were:
> 1. unique token per http request - not practical because there is no per
> http request event available
> 2. a whitelist of “remote” ports - not practical because there is no
> simple way to get a list of ports in use by WKWebView
>
> After going down this rathole and coming up empty, I reconsidered the
> original problem and came to the following conclusions.
> 1. restricting requests to localhost-only limits “attacks” to backgrounded
> apps
> 2. including a token in the requests will prevent backgrounded apps from
> being able to successfully make unwanted requests
> 3. the token is vulnerable to network analysis, but that cannot be done on
> device
>
> Therefore, vulnerability is limited to the case where the there is
> (1) a “hostile" app installed on device and running in the background and
> (2) the user’s device is connected to a wi-fi network where an attacker is
> able to perform network analysis to capture the token.
> In this case, the attacker could just inspect the HTTP traffic instead of
> capturing the token and sending it to their backgrounded app.
> In other words, it seems that replay attacks are possible but not useful.
> If we care about the “hostile wifi network” case, we need something like
> SSL.
>
> On 11/1/14, 4:28 PM, "Homer, Tony" <to...@intel.com> wrote:
>
> >I started looking at how to make the camera plugin be able to work in
> >WKWebView.
> >Before, I had mentioned intercepting resource requests as a way to fix the
> >file:// requests.
> >However, WKWebView does not offer a way to intercept resource requests so
> >that won’t work.
> >:/
> >
> >Andrew had suggested introducing some proxy paths as a way to deal with
> >the path problems, which seems fine.
> >On the other hand, the request handlers could just inspect the path in the
> >request and do the right thing - are the proxy paths needed?
> >I think implicit in those comments was a suggestion that the affected
> >plugins such as camera could return URLs using those paths.
> >The thing about changing camera and file plugins to support localhost that
> >bothers me, is that now those core plugins effectively support a non-core
> >plugin.
> >Also, other (on-cordova) plugins that depend on file protocol will be
> >incompatible with the local web server wkwebview solution (unless they
> >make changes to support it).
> >
> >I wonder if it would be better to handle this in CDVPluginResult?
> >A hook could be added to initWithStatus and exposed to plugins.
> >Then the SALocalWebServer plugin can use the hook to inspect the message
> >and fix it, if it is a file:// URL.
> >So, for example, when camera calls CDVPluginResult
> >resultWithStatus:messageAsString and passes in a file URL, SALocalServer
> >can get a chance to inspect and modify the result – changing it to an
> >http:localhost URL. It could simply replace the file protocol with
> >http://localhost:port, then the handler could decode the path before
> >building the response.
> >This is ugly, but it would prevent the need to change the camera and file
> >and should allow other non-cordova plugins that depend on file:// URLs to
> >work.
> >
> >
> >Tony
> >
> >On 10/31/14, 2:03 PM, "Homer, Tony" <to...@intel.com> wrote:
> >
> >>I started with cookies in my POC, but I was concerned about replay
> >>attacks.
> >>I couldn’t think of a way to avoid replay vulnerability with cookies
> >>(without SSL), so I was going to switch to the side channel approach I
> >>tried to describe. Do you think replay vulnerability is irrelevant? I’m
> >>not a security guy, so I wasn’t sure if it mattered or not. That’s
> >>actually one of the things I was hoping to get feedback about.
> >>
> >>I guess I don’t follow how CORS relates to the camera plugin, does it use
> >>XHR? Maybe you can elaborate?
> >>I expect I’ll see it when I try the camera plugin from WKWebView, just
> >>didn’t get around to it yet.
> >>The only thing that jumps out at me is that you get a file:// url back -
> >>we could change that.
> >>Or maybe intercept file:// requests in the plugin? If it’s just a path
> >>problem, maybe we could intercept the request, fix the path, then respond
> >>with the right thing...
> >>
> >>Tony
> >>
> >>On 10/31/14, 1:19 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
> >>
> >>>Unless you're having the server proxy requests to remote sites, I don't
> >>>think CORS headers are necessary.
> >>>
> >>>Tony - awesome stuff! absolutely doing it right. More technical-focused
> >>>discussion the better :). Using cookies seems the best way to me since
> >>>that
> >>>covers all requests. Adding headers works only for XHRs.
> >>>
> >>>On Fri, Oct 31, 2014 at 12:12 PM, Kirk Shoop (MS OPEN TECH) <
> >>>Kirk.Shoop@microsoft.com> wrote:
> >>>
> >>>> Yes, the handler should be able to add CORS headers to its responses
> >>>>that
> >>>> will enable requests from any origin.
> >>>>
> >>>> For instance adding 'Access-Control-Allow-Origin: *' would allow any
> >>>> origin to make a request from the local server.
> >>>>
> http://www.w3.org/TR/cors/#access-control-allow-origin-response-header
> >>>>
> >>>> Similarly Access-Control-Allow-Methods and
> >>>>Access-Control-Allow-Headers
> >>>> could be used to define valid requests.
> >>>>
> >>>> Kirk
> >>>>
> >>>> Developer
> >>>> Microsoft Open Technologies, Inc.
> >>>>
> >>>> -----Original Message-----
> >>>> From: Homer, Tony [mailto:tony.homer@intel.com]
> >>>> Sent: Friday, October 31, 2014 8:40 AM
> >>>> To: dev@cordova.apache.org
> >>>> Subject: Re: [iOS 8] WKWebView moving forward
> >>>>
> >>>> Last night I added a handler to the Local Web Server plugin that
> >>>>returns
> >>>> 403 for non-localhost requests.
> >>>> The handler also has a prototype token system to restrict requests to
> >>>>the
> >>>> app, but I need to change the approach a bit.
> >>>> Currently I set a cookie and the handler just checks for the cookie
> >>>>and
> >>>> returns 403 if it is missing.
> >>>> This is susceptible to replay attacks from backgrounded apps - not
> >>>>sure
> >>>>if
> >>>> that is important or not.
> >>>>
> >>>> I¹m going to investigate adding a map to the plugin, then add an entry
> >>>>for
> >>>> every request.
> >>>> The entry will be a hash of the request and a random number.
> >>>>
> >>>> I¹ll have to wire up support for overriding url loads so that I can
> >>>>add
> >>>> the header with the random number to the request.
> >>>> Then the request handler will look the entry up in the map and remove
> >>>>it -
> >>>> this should eliminate re-playability.
> >>>>
> >>>> I¹m not sure about the CORS issue with camera pluginŠ I¹ll be curious
> >>>>to
> >>>> test it - maybe it could be addressed by modifying the response in the
> >>>> GCDWebServer handler?
> >>>>
> >>>> Tony
> >>>>
> >>>> P.S. This is my first attempt participating in discussion on the list
> >>>>-
> >>>> let me know if I¹m doing it wrong!
> >>>> Am I wasting my time investigating this? Should I just leave it
> >>>>Shazron?
> >>>>
> >>>> On 10/30/14, 9:52 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
> >>>>
> >>>> >On Thu, Oct 30, 2014 at 5:05 PM, Shazron <sh...@gmail.com> wrote:
> >>>> >
> >>>> >> The port conflict situation has been solved with the latest version
> >>>> >>of the plugin. Passing in a port of "0" will choose a random port.
> >>>> >>More details in the plugin's README.md
> >>>> >>
> >>>> >Awesome! Why even allow a non-random port?
> >>>> >Also learned today that in chrome, webcrypto API is disabled for http
> >>>> >origins, but enabled for https. Not sure if this is true for Safari
> >>>>as
> >>>> >well, but certainly this change will be a can of worms!
> >>>> >
> >>>> >
> >>>> >>
> >>>> >> Ouch - didn't think about Camera plugin and File plugin impact.
> >>>>That
> >>>> >>proxy thing might work, as long as there are no folder name
> >>>> >>collisions.
> >>>> >>
> >>>> >Prefixing all resources into a fake top-level directory will
> >>>>eliminate
> >>>> >the folder name collision problem I think.
> >>>> >
> >>>> >
> >>>> >>
> >>>> >> My point regarding mixing WKWebView and UIWebView on iOS 8 is, if
> >>>>you
> >>>> >>have a user on iOS 8.x, you want all users on that iOS version to
> >>>> >>have the same experience, and for bug reporting purposes.
> >>>> >
> >>>> >
> >>>> >> On Wed, Oct 29, 2014 at 5:11 PM, Andrew Grieve
> >>>><ag...@chromium.org>
> >>>> >> wrote:
> >>>> >>
> >>>> >> > We could restrict access to the webserver by stuffing a cookie
> >>>>into
> >>>> >>the
> >>>> >> > webview with an access token, then have the server just 500 on
> >>>>any
> >>>> >> request
> >>>> >> > missing the cookie. We should also be able to restrict external
> >>>> >>requests
> >>>> >> > just by listening on 127.0.0.1 instead of 0.0.0.0 (doesn't look
> >>>> >> > like GCDWebServer supports this, but we can hack it in).
> >>>> >> >
> >>>> >> > The problem of port conflicts is annoying though. Maybe we try
> >>>>random
> >>>> >> ports
> >>>> >> > until one works? Is there any need to use the same port for
> >>>>multiple
> >>>> >> runs?
> >>>> >> >
> >>>> >> > The CORS thing is sad, because it also means things like Camera
> >>>>plugin
> >>>> >> will
> >>>> >> > be broken (can't use resulting URL in <img>).
> >>>> >> >
> >>>> >> > Although we might just do (this is different than the current
> >>>>mapping
> >>>> >>in
> >>>> >> > the plugin):
> >>>> >> > http://localhost:RANDOM_PORT/www
> >>>> >> > http://localhost:RANDOM_PORT/asset-library
> >>>> >> > http://localhost:RANDOM_PORT/file-system
> >>>> >> >
> >>>> >> > to proxy the three locations.
> >>>> >> >
> >>>> >> > This also means we can't use FileEntry.toURL() and have it work,
> >>>> >>unless
> >>>> >> > toURL returns http://localhost:RANDOM_PORT/file-system/...
> >>>>Maybe
> >>>> >> that's
> >>>> >> > fine?
> >>>> >> >
> >>>> >> >
> >>>> >> > I don't think it's weird that an app will need to support
> >>>>WKWebView on
> >>>> >> some
> >>>> >> > OS versions, and UIWebView on others. That's already the case to
> >>>> >>support
> >>>> >> > iOS 7.
> >>>> >> >
> >>>> >> >
> >>>> >> >
> >>>> >> > On Wed, Oct 29, 2014 at 6:22 PM, Shazron <sh...@gmail.com>
> >>>>wrote:
> >>>> >> >
> >>>> >> > > This does not preclude using the file url API function I
> >>>>suppose.
> >>>> >> Here's
> >>>> >> > a
> >>>> >> > > flowchart on how I think it would work:
> >>>> >>http://i.imgur.com/zq4zreN.png
> >>>> >> > >
> >>>> >> > >
> >>>> >> > > On Wed, Oct 29, 2014 at 2:48 PM, Tommy Williams
> >>>><tommy@devgeeks.org
> >>>> >
> >>>> >> > > wrote:
> >>>> >> > >
> >>>> >> > > > This whole thing reeks of sadness and pain.
> >>>> >> > > >
> >>>> >> > > > The security implications of this will have to be considered
> >>>>very
> >>>> >> > > > carefully.
> >>>> >> > > > On 29 Oct 2014 16:40, "Shazron" <sh...@apache.org> wrote:
> >>>> >> > > >
> >>>> >> > > > > ## What We Know So Far
> >>>> >> > > > >
> >>>> >> > > > > 1. Because of the file:// url loading bug, we couldn't
> >>>>support
> >>>> >>the
> >>>> >> > > > > WKWebView in the iOS 8 GM release. It has since been fixed,
> >>>>for
> >>>> >> > release
> >>>> >> > > > > post iOS 8.1 (not sure when), through a new WKWebView API
> >>>> >>function
> >>>> >> (
> >>>> >> > > > > http://trac.webkit.org/changeset/174029/trunk)
> >>>> >> > > > > 2. The alternative is embedding a local web server and
> >>>>serving
> >>>> >> assets
> >>>> >> > > > from
> >>>> >> > > > > that
> >>>> >> > > > >
> >>>> >> > > > > ## Abandon file:// url Loading API Method
> >>>> >> > > > >
> >>>> >> > > > > My proposal is, we abandon the local file:// url loading
> >>>>method
> >>>> >>in
> >>>> >> > (1)
> >>>> >> > > > > above, since it will create problems with support.
> >>>> >> > > > >
> >>>> >> > > > > For example, if we support the new local file url loading
> >>>>API
> >>>> >> > function
> >>>> >> > > in
> >>>> >> > > > > iOS 8.2.0 (speculated) -- and a user is on 8.0.2, what
> >>>>then?
> >>>>You
> >>>> >> > would
> >>>> >> > > > not
> >>>> >> > > > > have WKWebView support for that user, and you would use
> >>>> >>UIWebView
> >>>> >> > > > instead.
> >>>> >> > > > > This will just be confusing, and leads to problems.
> >>>> >> > > > >
> >>>> >> > > > > With the embedded local web server method, you can support
> >>>> >>**any**
> >>>> >> > > > version
> >>>> >> > > > > of iOS 8.x.
> >>>> >> > > > >
> >>>> >> > > > > ## Embrace Embedded Local Web Server Method
> >>>> >> > > > >
> >>>> >> > > > > I have a Cordova plugin that implements this, and it should
> >>>>work
> >>>> >> with
> >>>> >> > > > > cordova-ios 3.7.0:
> >>>> >> > > > > https://github.com/shazron/CordovaLocalWebServer
> >>>> >> > > > >
> >>>> >> > > > > It dynamically updates the <access> tag value when it
> >>>>loads,
> >>>> >> > overriding
> >>>> >> > > > it
> >>>> >> > > > > to the actual location and port. Since it is a plugin, it
> >>>>can be
> >>>> >> > > > swappable
> >>>> >> > > > > (for whatever reason).
> >>>> >> > > > >
> >>>> >> > > > > It does not solve the problem where any backgrounded app
> >>>>can
> >>>> >>access
> >>>> >> > our
> >>>> >> > > > > local web server.
> >>>> >> > > > >
> >>>> >> > > > > ## Future Steps
> >>>> >> > > > >
> >>>> >> > > > > This plugin is already working in cordova-ios 3.7.0
> >>>> >>(un-released,
> >>>> >> up
> >>>> >> > > next
> >>>> >> > > > > for vote release).
> >>>> >> > > > >
> >>>> >> > > > > The wkwebview branch:
> >>>> >> > > > >
> >>>> >> > > > > 1. Needs be rebased
> >>>> >> > > > > 2. Needs to be re-tested
> >>>> >> > > > > 3. issues in CB-7043 that relate to the wkwebview have to
> >>>>be
> >>>> >> resolved
> >>>> >> > > > > 4. branch presented for review to other committers
> >>>> >> > > > > 5. resolve any comments and issues from (4)
> >>>> >> > > > > 6. wkwebview branch integrated into master
> >>>> >> > > > >
> >>>> >> > > > > I will work on these items next after getting cordova-ios
> >>>>3.7.0
> >>>> >> out.
> >>>> >> > > Any
> >>>> >> > > > > help is welcome.
> >>>> >> > > > >
> >>>> >> > > > > ## Migration Issues
> >>>> >> > > > >
> >>>> >> > > > > If you are migrating to WKWebView from UIWebView, you will
> >>>>lose
> >>>> >> some
> >>>> >> > > > > functionality.
> >>>> >> > > > >
> >>>> >> > > > > 1. No more whitelist feature (NSURLProtocol is not
> >>>>supported
> >>>>in
> >>>> >> > > > WKWebView)
> >>>> >> > > > > 2. Your XmlHttpRequest calls now need to be CORS compliant
> >>>> >>(this is
> >>>> >> > > still
> >>>> >> > > > > true if loaded through a file:// url)
> >>>> >> > > > > 3. HTML5 offline application cache is not available in
> >>>> >>WKWebView (
> >>>> >> > > > > https://devforums.apple.com/message/1060452)
> >>>> >> > > > >
> >>>> >> > > >
> >>>> >> > >
> >>>> >> >
> >>>> >>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >>>> For additional commands, e-mail: dev-help@cordova.apache.org
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >>>> For additional commands, e-mail: dev-help@cordova.apache.org
> >>>>
> >>>>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
Re: [iOS 8] WKWebView moving forward
Posted by "Homer, Tony" <to...@intel.com>.
I spent a lot of time thinking about ways to avoid replay attacks for the
local web server plugin this weekend.
Specifically, I felt like there should be a way to take advantage of the
fact that the client and the server are running in the same process.
I thought this might enable some kind of sideband (non-http)
authentication possibility.
The 2 possibilities I was most interested in, but eventually concluded are
not practical were:
1. unique token per http request - not practical because there is no per
http request event available
2. a whitelist of “remote” ports - not practical because there is no
simple way to get a list of ports in use by WKWebView
After going down this rathole and coming up empty, I reconsidered the
original problem and came to the following conclusions.
1. restricting requests to localhost-only limits “attacks” to backgrounded
apps
2. including a token in the requests will prevent backgrounded apps from
being able to successfully make unwanted requests
3. the token is vulnerable to network analysis, but that cannot be done on
device
Therefore, vulnerability is limited to the case where the there is
(1) a “hostile" app installed on device and running in the background and
(2) the user’s device is connected to a wi-fi network where an attacker is
able to perform network analysis to capture the token.
In this case, the attacker could just inspect the HTTP traffic instead of
capturing the token and sending it to their backgrounded app.
In other words, it seems that replay attacks are possible but not useful.
If we care about the “hostile wifi network” case, we need something like
SSL.
On 11/1/14, 4:28 PM, "Homer, Tony" <to...@intel.com> wrote:
>I started looking at how to make the camera plugin be able to work in
>WKWebView.
>Before, I had mentioned intercepting resource requests as a way to fix the
>file:// requests.
>However, WKWebView does not offer a way to intercept resource requests so
>that won’t work.
>:/
>
>Andrew had suggested introducing some proxy paths as a way to deal with
>the path problems, which seems fine.
>On the other hand, the request handlers could just inspect the path in the
>request and do the right thing - are the proxy paths needed?
>I think implicit in those comments was a suggestion that the affected
>plugins such as camera could return URLs using those paths.
>The thing about changing camera and file plugins to support localhost that
>bothers me, is that now those core plugins effectively support a non-core
>plugin.
>Also, other (on-cordova) plugins that depend on file protocol will be
>incompatible with the local web server wkwebview solution (unless they
>make changes to support it).
>
>I wonder if it would be better to handle this in CDVPluginResult?
>A hook could be added to initWithStatus and exposed to plugins.
>Then the SALocalWebServer plugin can use the hook to inspect the message
>and fix it, if it is a file:// URL.
>So, for example, when camera calls CDVPluginResult
>resultWithStatus:messageAsString and passes in a file URL, SALocalServer
>can get a chance to inspect and modify the result – changing it to an
>http:localhost URL. It could simply replace the file protocol with
>http://localhost:port, then the handler could decode the path before
>building the response.
>This is ugly, but it would prevent the need to change the camera and file
>and should allow other non-cordova plugins that depend on file:// URLs to
>work.
>
>
>Tony
>
>On 10/31/14, 2:03 PM, "Homer, Tony" <to...@intel.com> wrote:
>
>>I started with cookies in my POC, but I was concerned about replay
>>attacks.
>>I couldn’t think of a way to avoid replay vulnerability with cookies
>>(without SSL), so I was going to switch to the side channel approach I
>>tried to describe. Do you think replay vulnerability is irrelevant? I’m
>>not a security guy, so I wasn’t sure if it mattered or not. That’s
>>actually one of the things I was hoping to get feedback about.
>>
>>I guess I don’t follow how CORS relates to the camera plugin, does it use
>>XHR? Maybe you can elaborate?
>>I expect I’ll see it when I try the camera plugin from WKWebView, just
>>didn’t get around to it yet.
>>The only thing that jumps out at me is that you get a file:// url back -
>>we could change that.
>>Or maybe intercept file:// requests in the plugin? If it’s just a path
>>problem, maybe we could intercept the request, fix the path, then respond
>>with the right thing...
>>
>>Tony
>>
>>On 10/31/14, 1:19 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
>>
>>>Unless you're having the server proxy requests to remote sites, I don't
>>>think CORS headers are necessary.
>>>
>>>Tony - awesome stuff! absolutely doing it right. More technical-focused
>>>discussion the better :). Using cookies seems the best way to me since
>>>that
>>>covers all requests. Adding headers works only for XHRs.
>>>
>>>On Fri, Oct 31, 2014 at 12:12 PM, Kirk Shoop (MS OPEN TECH) <
>>>Kirk.Shoop@microsoft.com> wrote:
>>>
>>>> Yes, the handler should be able to add CORS headers to its responses
>>>>that
>>>> will enable requests from any origin.
>>>>
>>>> For instance adding 'Access-Control-Allow-Origin: *' would allow any
>>>> origin to make a request from the local server.
>>>> http://www.w3.org/TR/cors/#access-control-allow-origin-response-header
>>>>
>>>> Similarly Access-Control-Allow-Methods and
>>>>Access-Control-Allow-Headers
>>>> could be used to define valid requests.
>>>>
>>>> Kirk
>>>>
>>>> Developer
>>>> Microsoft Open Technologies, Inc.
>>>>
>>>> -----Original Message-----
>>>> From: Homer, Tony [mailto:tony.homer@intel.com]
>>>> Sent: Friday, October 31, 2014 8:40 AM
>>>> To: dev@cordova.apache.org
>>>> Subject: Re: [iOS 8] WKWebView moving forward
>>>>
>>>> Last night I added a handler to the Local Web Server plugin that
>>>>returns
>>>> 403 for non-localhost requests.
>>>> The handler also has a prototype token system to restrict requests to
>>>>the
>>>> app, but I need to change the approach a bit.
>>>> Currently I set a cookie and the handler just checks for the cookie
>>>>and
>>>> returns 403 if it is missing.
>>>> This is susceptible to replay attacks from backgrounded apps - not
>>>>sure
>>>>if
>>>> that is important or not.
>>>>
>>>> I¹m going to investigate adding a map to the plugin, then add an entry
>>>>for
>>>> every request.
>>>> The entry will be a hash of the request and a random number.
>>>>
>>>> I¹ll have to wire up support for overriding url loads so that I can
>>>>add
>>>> the header with the random number to the request.
>>>> Then the request handler will look the entry up in the map and remove
>>>>it -
>>>> this should eliminate re-playability.
>>>>
>>>> I¹m not sure about the CORS issue with camera pluginŠ I¹ll be curious
>>>>to
>>>> test it - maybe it could be addressed by modifying the response in the
>>>> GCDWebServer handler?
>>>>
>>>> Tony
>>>>
>>>> P.S. This is my first attempt participating in discussion on the list
>>>>-
>>>> let me know if I¹m doing it wrong!
>>>> Am I wasting my time investigating this? Should I just leave it
>>>>Shazron?
>>>>
>>>> On 10/30/14, 9:52 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
>>>>
>>>> >On Thu, Oct 30, 2014 at 5:05 PM, Shazron <sh...@gmail.com> wrote:
>>>> >
>>>> >> The port conflict situation has been solved with the latest version
>>>> >>of the plugin. Passing in a port of "0" will choose a random port.
>>>> >>More details in the plugin's README.md
>>>> >>
>>>> >Awesome! Why even allow a non-random port?
>>>> >Also learned today that in chrome, webcrypto API is disabled for http
>>>> >origins, but enabled for https. Not sure if this is true for Safari
>>>>as
>>>> >well, but certainly this change will be a can of worms!
>>>> >
>>>> >
>>>> >>
>>>> >> Ouch - didn't think about Camera plugin and File plugin impact.
>>>>That
>>>> >>proxy thing might work, as long as there are no folder name
>>>> >>collisions.
>>>> >>
>>>> >Prefixing all resources into a fake top-level directory will
>>>>eliminate
>>>> >the folder name collision problem I think.
>>>> >
>>>> >
>>>> >>
>>>> >> My point regarding mixing WKWebView and UIWebView on iOS 8 is, if
>>>>you
>>>> >>have a user on iOS 8.x, you want all users on that iOS version to
>>>> >>have the same experience, and for bug reporting purposes.
>>>> >
>>>> >
>>>> >> On Wed, Oct 29, 2014 at 5:11 PM, Andrew Grieve
>>>><ag...@chromium.org>
>>>> >> wrote:
>>>> >>
>>>> >> > We could restrict access to the webserver by stuffing a cookie
>>>>into
>>>> >>the
>>>> >> > webview with an access token, then have the server just 500 on
>>>>any
>>>> >> request
>>>> >> > missing the cookie. We should also be able to restrict external
>>>> >>requests
>>>> >> > just by listening on 127.0.0.1 instead of 0.0.0.0 (doesn't look
>>>> >> > like GCDWebServer supports this, but we can hack it in).
>>>> >> >
>>>> >> > The problem of port conflicts is annoying though. Maybe we try
>>>>random
>>>> >> ports
>>>> >> > until one works? Is there any need to use the same port for
>>>>multiple
>>>> >> runs?
>>>> >> >
>>>> >> > The CORS thing is sad, because it also means things like Camera
>>>>plugin
>>>> >> will
>>>> >> > be broken (can't use resulting URL in <img>).
>>>> >> >
>>>> >> > Although we might just do (this is different than the current
>>>>mapping
>>>> >>in
>>>> >> > the plugin):
>>>> >> > http://localhost:RANDOM_PORT/www
>>>> >> > http://localhost:RANDOM_PORT/asset-library
>>>> >> > http://localhost:RANDOM_PORT/file-system
>>>> >> >
>>>> >> > to proxy the three locations.
>>>> >> >
>>>> >> > This also means we can't use FileEntry.toURL() and have it work,
>>>> >>unless
>>>> >> > toURL returns http://localhost:RANDOM_PORT/file-system/...
>>>>Maybe
>>>> >> that's
>>>> >> > fine?
>>>> >> >
>>>> >> >
>>>> >> > I don't think it's weird that an app will need to support
>>>>WKWebView on
>>>> >> some
>>>> >> > OS versions, and UIWebView on others. That's already the case to
>>>> >>support
>>>> >> > iOS 7.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > On Wed, Oct 29, 2014 at 6:22 PM, Shazron <sh...@gmail.com>
>>>>wrote:
>>>> >> >
>>>> >> > > This does not preclude using the file url API function I
>>>>suppose.
>>>> >> Here's
>>>> >> > a
>>>> >> > > flowchart on how I think it would work:
>>>> >>http://i.imgur.com/zq4zreN.png
>>>> >> > >
>>>> >> > >
>>>> >> > > On Wed, Oct 29, 2014 at 2:48 PM, Tommy Williams
>>>><tommy@devgeeks.org
>>>> >
>>>> >> > > wrote:
>>>> >> > >
>>>> >> > > > This whole thing reeks of sadness and pain.
>>>> >> > > >
>>>> >> > > > The security implications of this will have to be considered
>>>>very
>>>> >> > > > carefully.
>>>> >> > > > On 29 Oct 2014 16:40, "Shazron" <sh...@apache.org> wrote:
>>>> >> > > >
>>>> >> > > > > ## What We Know So Far
>>>> >> > > > >
>>>> >> > > > > 1. Because of the file:// url loading bug, we couldn't
>>>>support
>>>> >>the
>>>> >> > > > > WKWebView in the iOS 8 GM release. It has since been fixed,
>>>>for
>>>> >> > release
>>>> >> > > > > post iOS 8.1 (not sure when), through a new WKWebView API
>>>> >>function
>>>> >> (
>>>> >> > > > > http://trac.webkit.org/changeset/174029/trunk)
>>>> >> > > > > 2. The alternative is embedding a local web server and
>>>>serving
>>>> >> assets
>>>> >> > > > from
>>>> >> > > > > that
>>>> >> > > > >
>>>> >> > > > > ## Abandon file:// url Loading API Method
>>>> >> > > > >
>>>> >> > > > > My proposal is, we abandon the local file:// url loading
>>>>method
>>>> >>in
>>>> >> > (1)
>>>> >> > > > > above, since it will create problems with support.
>>>> >> > > > >
>>>> >> > > > > For example, if we support the new local file url loading
>>>>API
>>>> >> > function
>>>> >> > > in
>>>> >> > > > > iOS 8.2.0 (speculated) -- and a user is on 8.0.2, what
>>>>then?
>>>>You
>>>> >> > would
>>>> >> > > > not
>>>> >> > > > > have WKWebView support for that user, and you would use
>>>> >>UIWebView
>>>> >> > > > instead.
>>>> >> > > > > This will just be confusing, and leads to problems.
>>>> >> > > > >
>>>> >> > > > > With the embedded local web server method, you can support
>>>> >>**any**
>>>> >> > > > version
>>>> >> > > > > of iOS 8.x.
>>>> >> > > > >
>>>> >> > > > > ## Embrace Embedded Local Web Server Method
>>>> >> > > > >
>>>> >> > > > > I have a Cordova plugin that implements this, and it should
>>>>work
>>>> >> with
>>>> >> > > > > cordova-ios 3.7.0:
>>>> >> > > > > https://github.com/shazron/CordovaLocalWebServer
>>>> >> > > > >
>>>> >> > > > > It dynamically updates the <access> tag value when it
>>>>loads,
>>>> >> > overriding
>>>> >> > > > it
>>>> >> > > > > to the actual location and port. Since it is a plugin, it
>>>>can be
>>>> >> > > > swappable
>>>> >> > > > > (for whatever reason).
>>>> >> > > > >
>>>> >> > > > > It does not solve the problem where any backgrounded app
>>>>can
>>>> >>access
>>>> >> > our
>>>> >> > > > > local web server.
>>>> >> > > > >
>>>> >> > > > > ## Future Steps
>>>> >> > > > >
>>>> >> > > > > This plugin is already working in cordova-ios 3.7.0
>>>> >>(un-released,
>>>> >> up
>>>> >> > > next
>>>> >> > > > > for vote release).
>>>> >> > > > >
>>>> >> > > > > The wkwebview branch:
>>>> >> > > > >
>>>> >> > > > > 1. Needs be rebased
>>>> >> > > > > 2. Needs to be re-tested
>>>> >> > > > > 3. issues in CB-7043 that relate to the wkwebview have to
>>>>be
>>>> >> resolved
>>>> >> > > > > 4. branch presented for review to other committers
>>>> >> > > > > 5. resolve any comments and issues from (4)
>>>> >> > > > > 6. wkwebview branch integrated into master
>>>> >> > > > >
>>>> >> > > > > I will work on these items next after getting cordova-ios
>>>>3.7.0
>>>> >> out.
>>>> >> > > Any
>>>> >> > > > > help is welcome.
>>>> >> > > > >
>>>> >> > > > > ## Migration Issues
>>>> >> > > > >
>>>> >> > > > > If you are migrating to WKWebView from UIWebView, you will
>>>>lose
>>>> >> some
>>>> >> > > > > functionality.
>>>> >> > > > >
>>>> >> > > > > 1. No more whitelist feature (NSURLProtocol is not
>>>>supported
>>>>in
>>>> >> > > > WKWebView)
>>>> >> > > > > 2. Your XmlHttpRequest calls now need to be CORS compliant
>>>> >>(this is
>>>> >> > > still
>>>> >> > > > > true if loaded through a file:// url)
>>>> >> > > > > 3. HTML5 offline application cache is not available in
>>>> >>WKWebView (
>>>> >> > > > > https://devforums.apple.com/message/1060452)
>>>> >> > > > >
>>>> >> > > >
>>>> >> > >
>>>> >> >
>>>> >>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>>>> For additional commands, e-mail: dev-help@cordova.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>>>> For additional commands, e-mail: dev-help@cordova.apache.org
>>>>
>>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org