Re: [guardian-dev] Crypto export regulations for apps on Google Play
On Wed, Oct 22, 2014, at 19:31, Hans-Christoph Steiner wrote: There is a page on guardianproject.info somewhere that we email to the US Gov. You presumably mean: https://guardianproject.info/home/export-information/ -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _The Busy Coder's Guide to Android Development_ Version 6.1: Wear? There! ___ Guardian-dev mailing list Post: Guardian-dev@lists.mayfirst.org List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To Unsubscribe Send email to: guardian-dev-unsubscr...@lists.mayfirst.org Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/archive%40mail-archive.com You are subscribed as: arch...@mail-archive.com
[guardian-dev] NetCipher: How Do I Know That It Is Working?
If I am writing an app, and I (try to) integrate NetCipher, and I make an HTTP request of a regular Web server, and I get a valid response back... how do I know that the request made it through Orbot's HTTP proxy and Tor, versus somehow being re-routed to the Web server directly? I have tried enabling "Debug Log" in Orbot, but I do not know if it logs request information (or what that might look like), and I do not know if anything is needed beyond checking the checkbox (e.g., restart Orbot, reboot device). Thanks! -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
[guardian-dev] NetCipher Book Chapter, and HTTP Stack Integration
I have written a chapter for _The Busy Coder's Guide to Android Development_ on the use of NetCipher. Along the way, I wrote integration code to tie NetCipher into: - OkHttp3 (including using it with Retrofit) - HttpURLConnection - Apache's independent packaging of HttpClient - Volley Here is the draft chapter, in PDF form: https://commonsware.com/misc/NetCipher.pdf One section is missing towards the end (you'll see a "TBD" there), but it is otherwise complete. Forgive the sidebars, but since this is a new chapter, it gets those on the first book update containing the chapter. Here is a ZIP file containing the sample project and HTTP integration code: https://commonsware.com/misc/HTTPStacks.zip When I ship the book update containing this chapter in the second half of March, I'll release a copy of this chapter under a Creative Commons license. Also, the HTTP integration code is all Apache License 2.0; you are welcome to any of that if you want it. I welcome any feedback on the prose or the code! -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
Re: [guardian-dev] NetCipher Book Chapter, and HTTP Stack Integration
On Thu, Feb 25, 2016, at 08:01, Hans-Christoph Steiner wrote: > Any chance of viewing this in git? Not until it gets released. At that point, it will be in my book's massive repo (https://github.com/commonsguy/cw-omnibus), along with the rest of my book samples. > I'll start digging into these. I looked at netcipher-hurl, that seems > to be a simplified duplication of what's already in the > NetCipher.getHttpURLConnection() methods, based on the > TlsOnlySocketFactory.java class. Was that deliberate? No. My biggest problem with all of this is that NetCipher is undocumented AFAICT. Hence, I worked off of the sample app to determine what is and is not your supported API. I didn't notice a getHttpURLConnection() method. I'll run a comparison and make changes if needed -- thanks! > > I do not believe that setPackage() is sufficient, for the Orbot status > > Intent, to get Orbot to run after a fresh installation, if the user has not > > run the Orbot activity. As of Android 3.1, apps are installed in a > > so-called “stopped state”, where manifest-registered receivers will not > > receive broadcasts of implict Intents. Using an explicit Intent, as I am, > > will help here. > > Ok, that's interesting. I couldn't find where you are making an > explicit Intent for this. That's inside validateBroadcastIntent(), over in my CWAC-Security library. For the purposes of my book, having it there is fine. For any long-term NetCipher reuse, we'd want to copy the logic from there or do something equivalent, so there's no dependency on something tiny like this: https://github.com/commonsguy/cwac-security/blob/master/security/src/main/java/com/commonsware/cwac/security/SignatureUtils.java#L70-L152 > It could easily take Orbot more than 30 seconds to complete the whole > Tor startup sequence. That's a key reason for the Intent broadcasts > with the OFF/STARTING/ON/STOPPING status. That let's the app then > respond accordingly, like holding network connections when in the > STARTING state. StatusCallback could be expanded for the other states. Again, it's not obvious what is and is not part of the supported API. Expanding StatusCallback is out of scope for the current book sample (like your sample, it doesn't really need it), but it's clearly something that could be added as part of any long-term NetCipher reuse. > I think we should skip that approach entirely, and leave only where it > was used for backwards compatibility. AndroidPinning provides a more > manageable approach to certificate pinning. If you are interested in > looking more into that, it could be a new chunk of work related to this. If you mean https://github.com/moxie0/AndroidPinning, that's GPLv3. Thanks! -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
Re: [guardian-dev] NetCipher Book Chapter, and HTTP Stack Integration
On Fri, Feb 26, 2016, at 08:43, Hans-Christoph Steiner wrote: > I tried a bit using setComponent() and a freshly installed and not > started Orbot. That did not seem to start it either. Does the "allow other apps to start Orbot" setting come pre-checked? If not, that may be the source of the difficulty. -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
Re: [guardian-dev] NetCipher: How Do I Know That It Is Working?
On Sun, Feb 14, 2016, at 01:21, grarpamp wrote: > https://check.torproject.org/api/ip > But that's only for browsers. I'd argue it's for Web service clients as well, which happens to be my test case. A JSON return payload is very cool, and it seems to be working. Many thanks! -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
Re: [guardian-dev] NetCipher Tests
On Tue, Mar 29, 2016, at 12:50, Hans-Christoph Steiner wrote: > If option #2 or #3 custom build.gradle is easy to do, I think that's the > best way for right now since its the lowest impact. OK. Unless you have a strong preference for option #3, I'll start with option #2. Thanks! -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
Re: [guardian-dev] NetCipher Book Chapter, and HTTP Stack Integration
On Fri, Mar 25, 2016, at 05:36, Hans-Christoph Steiner wrote: > * why did you use the custom WeakSet class rather than just a plain Set? To help prevent memory leaks, in case clients fail to unregister their callbacks. > * keep things as a JAR as much as possible, not an AAR, i.e. by avoiding > string resources, etc. I find it makes the library a lot easier to > deploy in a variety of situations (ant!). What do you want to do about the keystore? In my sample, I moved that to an asset, as I was having problems referencing the raw resource across library module boundaries. However, if you're aiming to change packaging to be a JAR instead of your current AAR, then the keystore cannot be either a raw resource or an asset. Options include: - Remove the keystore references from my code entirely, with an eye towards revamping all this (e.g., your proposed "make it look like Android N" approach). - Leave the keystore references more or less as-is, and tell users of the library that they need to put the keystore in the proper spot in assets/ (i.e., the old SQLCipher approach, before they switched to the AAR). - Add something (to OrbotHelper?) that exposes the keystore from raw resources via a Java API, then have my code use that API, and leave the raw resource where it is, requiring AAR packaging. - Attempt to switch this to an old-style Java JAR resource (note: not recommended, as I worry that the Android tools team will eventually break that). And there may be other options that I'm not thinking of, as I just woke up. > If you want to do it via pull requests, I'd do it one per HTTP API, and > another for the Orbot stuff. I'm not aware of other options for getting my stuff into your repo, other than pull requests, and possibly butterflies. https://xkcd.com/378/ Thanks! -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
Re: [guardian-dev] SNI with NetCipher's HttpsURLConnection
On Fri, Mar 18, 2016, at 06:52, Hans-Christoph Steiner wrote: > Also, to use the K-9 technique that does not use reflection, > TlsOnlySocketFactory will need to be a subclass of > SSLCertificateSocketFactory rather than SSLSocketFactory. I think > that's probably the best approach. Agreed. I didn't do that in the work that I did for my book chapter, to minimize changes to NetCipher's core code. This area was the only thing that I needed to change anything in existing NetCipher, and I figured that adding a stopgap method to TlsOnlySocketFactory was less intrusive than changing its base class. -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
Re: [guardian-dev] SNI with NetCipher's HttpsURLConnection
On Wed, Mar 2, 2016, at 16:31, cketti wrote: > On 24.02.2016 21:12, Hans-Christoph Steiner wrote: > > Anyone have any pointers? NetCipher should really fully support SNI. > > This might help: https://github.com/k9mail/k-9/pull/718 HttpClient has the same SNI problem, even without NetCipher. Their fix (https://wiki.apache.org/HttpComponents/SNISupport) is akin to yours. I really dislike using reflection hacks for workarounds, but I'm guessing that there aren't other options here. Thanks for pointing this out! -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
Re: [guardian-dev] where to buy an Android device without Google Play on it?
On Mon, Apr 4, 2016, at 06:25, Hans-Christoph Steiner wrote: > Since Google Play is blocked in China, I imagine that phones sold in > China do not come with Google Play installed. I recently bought two > Chinese phone models, a Xiaomi Redphone 3 and a Lenovo A2800. Both of > them are fully branded in Chinese, and the A2800 is actually marked > "China Mobile", then China-only telecom. Both of these came with Google > Play installed. So either Google Play is installed on phones sold in > China, or I'm getting other editions like Hong Kong or Taiwan. > > Has anyone bought Android devices that come without Google Play > installed? There is always the Amazon Kindle Fire series. -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
Re: [guardian-dev] NetCipher Book Chapter, and HTTP Stack Integration
On Mon, Mar 28, 2016, at 07:42, Hans-Christoph Steiner wrote: > > To help prevent memory leaks, in case clients fail to unregister their > > callbacks. > > I'd prefer to error/warn the user about this rather than reducing the > impact of doing the wrong thing. I vaguely remember seeing such > warnings in logcat. You have *far* greater faith in software developers than I do. > I'm saying remove the keystore references from your code entirely, for > now at least. OK, will do. With luck, I will submit pull requests later this week. -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
Re: [guardian-dev] netcipher integrated pinning idea
On Mon, Mar 28, 2016, at 13:42, Hans-Christoph Steiner wrote: > So NetCipher's ch.boye for a long time has included the ability to use a > custom keystore. Mark and I have been thinking that this could be a > good approach for a form of integrated pinning in the NetCipher wrappers > for all of the various HTTP APIs (HttpURLConnection, Apache HttpClient > for Android, Volley, OkHTTP, etc). The core idea would be a gradle > plugin or script that downloads the Mozilla CA certificates collection, > then fines the CA used by a provided HTTPS connection, then builds a > custom keystore that only includes that specific CA's certificate from > the Mozilla collection (turns out that Android N is including something > very similar). To clarify: what Android N offers is custom CA validation and certificate pinning, baked into the framework. It does not have the automatic generation of the credentials, leaving that up to you. Also, it does not use keystores, but rather PEM or DER files. See: http://developer.android.com/preview/features/security-config.html So, there are two pieces to your proposed puzzle: 1. A Gradle plugin that generates the PEM/DER file(s) (at minimum) necessary to lock an app down to only support certain CAs, based on the root CA of the certificate chain for an HTTPS connection 2. A quasi-backport of the Android N network security configuration stuff, presumably to integrate with NetCipher, where we apply the same security configuration on Android 6.0 and older devices Those are more-or-less independent: the plugin could be used for an app with a minSdkVersion of N, and the backport could be used without the plugin (e.g., for certificate pinning). Both seem to have merit, though I think the latter one is more important, if we can pull it off. Backwards compatibility is A Very Good Thing for adoption, and while Google might offer their own backport of this stuff, my guess is that they will not. -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
Re: [guardian-dev] "Enable SNI" pull request CI build is now failing
On Mon, Apr 25, 2016, at 09:45, Hans-Christoph Steiner wrote: > The CI build is now failing with the most recent addition to your pull > request. Yes, I noticed that after pushing the change. :-( > This seems to be the error: > > java.net.UnknownHostException: Unable to resolve host "yahoo.com": No > address associated with hostname > > at java.net.InetAddress.lookupHostByName(InetAddress.java:457) > > Strange error, it could just be a hiccup in the travis-ci build machine. Since there isn't anything that I did that should affect hostname lookups, I have assumed that this is some networking issue related to whatever the CI server is doing for testing Android apps. Is there a way to request an on-demand CI server test run? What I might do is manually run the CI server tests before submitting future pull requests, to see if the pull request itself caused test result changes on the CI server. -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
[guardian-dev] NetCipher: WeakSet Alternatives
In my work on tying NetCipher into various HTTP stacks, I wanted a WeakSet: a collection where the values were held weakly. This is for callback/listener interfaces, so if the party that registers a listener fails to unregister, a singleton does not trigger a memory leak. Unfortunately, the one WeakSet implementation that I found is buggy. :-( The canonical solution for Java is to use Collections#newSetFromMap() on a WeakHashMap. WeakHashMap holds the keys weakly; newSetFromMap() creates a Set interface on top of the Map's keys. However, newSetFromMap() was only added to Android with API Level 9. Options: 1. Say "screw it" and use a regular HashSet, and if there's a memory leak, it's the job of the developer using NetCipher to detect and address it (since, in truth, they are screwing up). 2. Set NetCipher's minSdkVersion to 9, up from its current 8. 3. Just use WeakHashMap directly, only paying attention to the keys. This will make the code a little funny looking, but it'll work. 4. See if I can find an Apache Harmony edition of Collections from which we can get an Apache-licensed newSetFromMap() implementation. My guess is that there is none, otherwise Android would have had this method from API Level 1. Thoughts? -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
Re: [guardian-dev] NetCipher: Integrate Tor Status Check?
On Fri, May 13, 2016, at 02:40, Hans-Christoph Steiner wrote: > I like the idea of enforcing by default, but I worry about unintended > consequences of checking https://check.torproject.org/api/ip before > setting up an instance. Perhaps it is something like the check whether > Orbot is installed: run only on the first time NetCipher is used to get > an HTTP stack instance. Sorry, that's what I meant. Not every connection; just once per process, after we get the proxy port but before we hand the *first* client object back to the app. > Also, for what its worth, .onion addresses would not need any > https://check.torproject.org/api/ip checks since they only work through > Tor. OrbotHelper won't know that URL at the time it is doing the confirmation, though, so it needs to confirm regardless of what URLs might get used by the app. -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
[guardian-dev] FYI: Android N Network Security Configuration Code
Google has published enough Android N code that we have access to the stuff for their network security configuration feature. This allows developers to provide certificates for custom CAs, for overriding Android's default CAs, and self-signed certificates, plus support for certificate pinning: https://github.com/android/platform_frameworks_base/tree/android-n-preview-2/core/java/android/security/net/config Their code relies fairly heavily on conscrypt, secondarily on libcore. It also has a few things that only work on API Level 19+. As a result, my guess is that Google will not provide a backport, or at least whoever wrote this code was not expecting a backport. However, it does seem to route all its logic through an X509TrustManager, and some of the ickier libcore dependencies lie outside of that. So, if conscrypt can be replaced by spongycastle, an independent backport of the core functionality is not out of the question, which should be easier than a cleanroom implementation from the specification. Anyway, just an FYI, in case anyone's been pondering this stuff... -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
Re: [guardian-dev] NetCipher v2 alpha: supports OkHTTP, Volley, HttpClient and more
On Sat, Aug 13, 2016, at 09:49, Vanitas Vitae wrote: > I want to use NetCipher in my application, but I get an error for the > line > > compile 'info.guardianproject.netcipher-webkit:netcipher:2.0.0-alpha1' > > Android Studio tells me, that the library cannot be found. I run into the same problem with 'info.guardianproject.netcipher-okhttp3:netcipher:2.0.0-alpha1'. Are you sure that these artifacts have been published? -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
[guardian-dev] CWAC-NetSecurity: Android 7.0 Network Security Configuration Backport
In case anyone's interested, I created a backport of the Android 7.0 network security configuration subsystem: https://github.com/commonsguy/cwac-netsecurity It works well with OkHttp3, so-so with HttpURLConnection, and other interested parties could create bridges to connect it to other HTTP client APIs. It works back to API Level 17 (Android 4.2). -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
Re: [guardian-dev] CWAC-NetSecurity: Android 7.0 Network Security Configuration Backport
On Thu, Jul 21, 2016, at 10:16, Hans-Christoph Steiner wrote: > do you think there would be a way to dynamically add supported CAs using > this API? The native Android 7.0 implementation does not support this. This backport could, at least in theory. I would need to make the ConfigSource version of withConfig() on TrustManagerBuilder public, which is not a big deal. And, you would have to implement a ConfigSource that implements your rules, and that may be tricky, given that I've never done it. I have relied on the AOSP ConfigSource implementations (XmlConfigSource and ManifestConfigSource) and have not looked into how easy or difficult it is to create a new one. There are 3+ implementations in the AOSP code IIRC, so it's probably reasonably flexible. TrustManagerBuilder also supports blending in arbitrary X509TrustManager implementations, using boolean operators. That's how NetCipher should be able to be connected in. I plan on testing that once new NetCipher artifacts are published (hint, hint :-). I have some code in the old TrustManagerBuilder (back in CWAC-Security) that implemented custom certificate/CA support TrustManagers. I didn't carry that forward, figuring that the AOSP code was probably more robust. If needed, I could always bring that code back from the dead. > Taking F-Droid or ChatSecure as an example: someone uses their own > server, when the new server is added to the app, can the app then do a > TOFU trust of the CA used for that server using this API? TOFU implies certificate memorization, not CA configuration, at least in terms of how I think of it. CA configuration would require that the app have access to the public cert file (PEM, DER). Certificate memorization with TOFU would not. I have some memorization code, also carried over from the old TrustManagerBuilder implementation. However, it dawned on me that this really needs to be a per-domain TOFU, and my implementation didn't handle that. So, that's still on my to-do list. The AOSP code does not offer memorization, at least not at present, so that would be handled purely by TrustManagerBuilder, not the backport. -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
Re: [guardian-dev] help with netcipher
On Sun, Jan 22, 2017, at 11:21, arrase wrote: > How do you deal with the lag between onEnabled callback of OrbotHelper > and onConnected callback of okhttp3 and the real available state of > 127.0.0.1:8118? There should be no lag. > I init orbothelper, when onEnabled is called i init > StrongOkHttpClientBuilder then when onConnected is called i run > okHttpClient.newCall(request).execute() but orbot is not yet available > and > i get: > > System.err: java.net.ConnectException: Failed to connect to > /127.0.0.1:8118 > > If i try again it works. If onEnabled() is called, that means that we received a STATUS_ON response from Orbot, which should mean that Orbot is accepting requests. Can you reproduce the problem with the sample apps (e.g., sample-okhttp3) or the test suite (in netcipher-okhttp3)? If so, what version of Android and Orbot are you using? -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
Re: [guardian-dev] help with netcipher
On Sun, Jan 22, 2017, at 12:21, arrase wrote: > i can not find a place at orbot code where the > app waits for Polipo before broadcast the state I do not know what Polipo is, sorry. If Orbot is sending STATUS_OK without being ready to accept connections, then either I misunderstood what STATUS_ON means, or Orbot has a bug. With luck, somebody more familiar with Orbot's implementation can comment. I generally treat Orbot as a black box. While we should get this problem fixed, to some extent, you need to handle this sort of problem anyway. For example, the server you are trying to reach may be unavailable, in which case I would expect that you will get an IOException of some form. Or, the device may not have a working Internet connection, in which case I would also expect an IOException. So, you will need some form of retry policy (e.g., try X times, with exponential backoff, before giving up and raising a Notification to the user about the problem). -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
Re: [guardian-dev] help with netcipher
On Sat, Jan 21, 2017, at 15:49, arrase wrote: > And then is called: > > public void onConnectionException(Exception e) What does the stack trace associated with the exception tell you? -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
Re: [guardian-dev] help with netcipher
On Tue, Jan 24, 2017, at 05:41, Hans-Christoph Steiner wrote: > Where did STATUS_OK come from, or is that just a typo? "Typo" implies just a typing error. I think I was having a synapse segfault and kept thinking the name was STATUS_OK instead of STATUS_ON. My apologies for the confusion. Also, thanks for the clarification! -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
Re: [guardian-dev] supporting SOCKS on Android via a custom SocketFactory
On Tue, Sep 6, 2016, at 05:48, Hans-Christoph Steiner wrote: > Could we use this approach in NetCipher? IIRC, NetCipher has SOCKS support. The exception is with OkHttpClient, and that's because Square is not explicitly supporting SOCKS with OkHttp3: https://github.com/square/okhttp/issues/2315 -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
Re: [guardian-dev] test when proxying WebView
On Wed, Sep 28, 2016, at 06:35, Hans-Christoph Steiner wrote: > I'm wondering if there > is a way to automatically test whether the WebView proxying is working? You can try hitting a known-Tor page (e.g., the Tor status check URL that NetCipher uses), then try to get the contents of the WebView: http://stackoverflow.com/questions/19518950/get-the-html-code-from-loaded-webview -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
Re: [guardian-dev] Hi, i' new
On Tue, Nov 22, 2016, at 19:57, arrase wrote: > Ouch! the app builds but: > > AndroidRuntime: java.lang.RuntimeException: Unable to get provider > com.commonsware.cwac.provider.StreamProvider: > java.lang.IllegalArgumentException: Failed to parse > com.commonsware.cwac.provider.STREAM_PROVIDER_PATHS meta-data You did not replace android:name with the fully-qualified class name of your StreamProvider subclass. StreamProvider does not know about your custom tag. For further help with StreamProvider, please use: https://github.com/commonsguy/cwac-provider#questions -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
Re: [guardian-dev] NetCipher interface for anonymity configurations
On Sun, Nov 13, 2016, at 04:22, Hans-Christoph Steiner wrote: > For example: > > * TLS Session Identifiers/Tickets I have limited experience in this area and so cannot comment authoritatively. My gut tells me that it'll be impractical for NetCipher to affect, as app developers have very little visibility into the SSL communications processing, and even less on Android 7.0+ (as Conscrypt/network security configuration takes over that work). > * detailed info in HTTP User Agent > * HTTP ETag With HTTP headers, usually, last one in wins. That's a problem, as NetCipher is not the one executing the HTTP request. The app is. NetCipher sets up an HTTP client API object (e.g., an HttpURLConnection, an OkHttpClient) with some stuff pre-configured. NetCipher then hands that over to the app, which makes the call. If NetCipher sets the header, and the app sets the header, the app's header will win. And, by "the app", I really mean, "the app's own code plus the code of any other libraries that the developer is using that might be working with the HTTP client object" (e.g., libraries like Retrofit or Picasso, that use an OkHttpClient). Now, if you're willing to say, "NetCipher will do the right thing, and if the developer overrides it, that's the developer's problem", that's doable. > But since some of these things provide substantial speed > improvements, we need to provide a way to disable them. That would mostly be a matter of adding disable methods to the StrongBuilder classes, and using that info when configuring the HTTP client API objects. > One idea would be to tell devs to use plain networking when going direct > and not through Tor. What is "plain networking" in this context? > Another would be to have methods to disable > specific settings. I'm hoping to open up the discussion to hear other > ideas. While the StrongBuilder system right now assumes that the point is to try to run through Tor, it could be change that Tor itself is an optional thing. In that case, the StrongBuilders would configure this other stuff and skip setting up the Tor proxy hooks. -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
Re: [guardian-dev] Fwd: [Android eng] FYI Android Studio 3.0 may inject profiler files into APK
On Fri, Dec 1, 2017, at 04:38, Hans-Christoph Steiner wrote: > Oy, Google, what are you doing? It seems that their lesson from > XCodeGhost is to use that technique to insert their own code, hidden > from view. > > Yay for reproducible builds! These files are not added to the APK, nor are they referenced from the APK anywhere that I can find. I'm assuming that they're doing some fancy stuff to add them to the running process. The code in the perfa.jar appears to be derived from: https://github.com/JetBrains/adt-tools-base/tree/master/profiler/supportlib/src/main/java/com/android/tools/profiler/support but that is two years old and is missing stuff that I see in the decompiled JAR. I filed an issue to try to get them to offer an option to disable this functionality: https://issuetracker.google.com/issues/70019396 -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
[guardian-dev] FYI: Facebook "Secure the Internet" Grant Program
https://research.fb.com/programs/research-awards/proposals/secure-the-internet-grants/ "Facebook is pleased to invite submissions from university researchers and faculty, non-profit organizations, and NGOs for applied research proposals to improve the security, privacy, and safety of internet users. Our goal is to spur development of technology that may be applied in practice, rather than pure research..." I wonder a bit about how unrestricted the "unrestricted gift" is, but this program might be of interest to established non-profits in this space. -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
Re: [guardian-dev] Android locking down private APIs
On Fri, Apr 6, 2018, at 03:48, Hans-Christoph Steiner wrote: > So Google is working to lock down more private APIs in both C/C++ and > Java: > https://android-developers.googleblog.com/2018/02/improving-stability-by-reducing-usage.html > > They ask for bug reports for private APIs that are needed. We should > file bugs about the proxy support that we need, i.e. the stuff using > reflection to add proxying to WebViews. I couldn't find an issue in > their tracker, and I didn't know the details enough to file the bug myself. You can't see any of these issues in the tracker, as the relevant component is private: https://issuetracker.google.com/issues?q=componentid:328403 You can file issues (https://issuetracker.google.com/issues/new?component=328403=1027267), and I assume that you can see your own issues, but you can't see what anyone else has filed. Security by obscurity, I guess. -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
Re: [guardian-dev] Orbot 16.0.5-RC-2-tor-0.3.4.9
On Fri, Dec 14, 2018, at 15:08, Nathan of Guardian wrote: > There was a particularly bad crash relating to > startForegroundService()->onStartCommand()->startForeground() that keeps > catching me. Essentially, if you don't call startForeground() fast > enough in onStartCommand(), or at all, every time your service is > launched with startForegroundService() then you get a crash, on some > indeterminate set of "strict" devices. FWIW, that crash should occur on all Android 8.0+ devices. -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
[guardian-dev] Seeking Jetpack Compose Security Concerns
As you may be aware, Google is working on Jetpack Compose, a next-generation UI toolkit for Android apps, effectively replacing the existing View-based system that we have been using since the beginning. Barring unexpected technical problems, I expect Compose to be Google's Android UI focus for the next decade. Since it is being developed in the open, and since it is still early in developer previews, we have a wonderful opportunity to try to ensure that this toolkit handles security-related scenarios well. If you find security-related concerns in Compose, file issues! If you know of security-related concerns in the existing View system, and you want me to try to determine if Compose suffers from similar problems, reach out! As an example, we use FLAG_SECURE to have a window block screenshots and screencasts. However, Android lacks any concept of window inheritance or ownership, so you have to put FLAG_SECURE on each window that needs to be secured. Unfortunately, Google created lots of windows without giving us any opportunity to add that flag, so we cannot readily secure our menus, Spinner and similar drop-downs, toasts, and so on. See https://github.com/commonsguy/cwac-security/blob/master/docs/FLAGSECURE.md for more on that. As it turns out, Compose also creates windows, and it presently does not give us the ability to add FLAG_SECURE to them. So, I filed issues for that: https://issuetracker.google.com/issues/143778148 https://issuetracker.google.com/issues/143778149 Next weekend, I plan to look at text entry in Compose and confirm that we have a way of avoiding String objects, so passphrases can be zero'd out and we don't have plaintext passphrases floating around our heap unnecessarily. That's the sort of thing that we need to try to identify. In theory, since Compose is shipped as libraries, this sort of thing can be improved later (unlike framework classes that are baked into the firmware). In practice, large code bases tend to ossify, and so the longer problems linger, the less likely it is that we will be able to get them fixed. Thanks in advance for any suggestions or support! -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
Re: [guardian-dev] Seeking Jetpack Compose Security Concerns
On Mon, Nov 4, 2019, at 05:08, Hans-Christoph Steiner wrote: > Thanks for all your work tracking and pushing stuff like this! Sounds > like you're already raising some key points. I haven't looked at this > at all yet. I must say: such a drastic change sounds scary in terms of > the amount of work it'll take to move apps. It is really warranted to > ditch the whole View structure? It depends on how you define "ditch". There is a View in the end, because Activity needs one. However, that View has a Canvas, and all the composable functions that make up a Compose UI just draw on that Canvas. So, the view hierarchy has a very shallow depth, with all of the real application logic all in one View. In terms of the level of effort to move apps... I expect it to be a bit more difficult than the effort to move from Java to Kotlin. More code is affected in the Java -> Kotlin migration, as not all Android app code is tied to the UI. However, I expect that the View -> Compose migration will be more manual. In terms of whether any of this is "warranted"... Google has their reasons (maintainability, more open, first-class reactive implementation, etc.). The bigger thing is that Google will be steering developers to use it, which means the next generation of Android developers will start with Compose. So, while Compose is still nicely malleable, we need to try to make sure that it doesn't screw up security. -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
Re: [guardian-dev] Manipulating App Bundles
On Wed, Jun 17, 2020, at 19:08, Nathan of Guardian wrote: > > I am sincerely hoping that I'm forgetting something that prevents this. > > I don't think you are. If there was some kind of binary transparency > where you could see all the builds that were done and released, that > might be a small step... But still, once they have your private signing > key, they can do anything they please. Yeah, I thought so. So, I'm going to poke the bear and see what happens. If anyone has any feedback on the attached draft blog post, I am up for any suggestions! Note: I mention F-Droid, as their policy had been to sign apps with their own signing key. It looks like now that there are some options for avoiding this, but I felt the need to address this head on. -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguyIn Milena Nikolic’s “What’s New in Google Play” presentation, she said: As we continue to improve the App Bundle, we expect it to become a requirement for all new apps sometime in 2021. I have not talked about the App Bundle much, other than privately steering developers away from it. Technically speaking, I am not opposed to the App Bundle itself. But, I am vehemently opposed to one “feature” of App Bundles: Google signs them. So, if Google is going to going to start forcing App Bundles on developers, we need to focus on the risks inherent in Google signing your apps. The Folly of Forbearance In a Medium post, Wojtek KaliciÅski wrote: we donât modify and distribute your application code without your knowledge and approval and: As stated before, Play will not modify the functionality of your application without your knowledge and approval. Notably, he used “don’t” and “will not”… as opposed to “can’t” and “cannot”. Google is perfectly capable of changing anything that they want in your app. You are what you sign. If Google signs the app, in reality Google is the developer of the app, controlling what is in it. You just did all the work. Google readily admits that they modify the app from what you give them as the App Bundle. Most notably, they subdivide the App Bundle into APKs that allow them to distribute a subset of your app, stripping out things that the user does not need, based upon device capability. Mr. KaliciÅski also stated that: For apps uploaded as app bundles, we will improve this security by introducing what is called a source stamp. This source metadata is inserted into the appâs manifest by bundletool. So, Google is already modifying your app. They just are claiming that this is all that they modify of your app. This is a policy of forbearance. They are capable of doing much more, but they are deciding not to do so at the present time. However, policies can change, at any time, for any reason, without warning. Or, as some guy in a dark helmet once said: I am altering the deal. Pray I don’t alter it any further. They could add DRM, or automatically collect analytics, or enforce other rules. The Amazon AppStore for Android does these things, courtesy of them re-signing your app: Amazon removes your signature and re-signs your app with an Amazon signature that is unique to you, does not change, and is the same for all apps in your account. In other words, Amazon is doing today — and has been doing for nearly a decade — what Google could be doing. Or, Google could wind up doing things even worse than DRM. Repression as a Service Let’s consider a hypothetical scenario: A country ruled by a repressive regime is oppressing a minority group. The leadership of that regime tells Google: “In order to do business in our country, you need to agree to distribute altered versions of apps to users of our choosing. We will supply you with the altered apps, and we will supply you with the identities or criteria for choosing the users who should receive these altered apps.” They then supply Google with the identities of leaders of the minority group, along with altered versions of Signal, WhatsApp, Zoom, and other end-to-end (E2E) encrypted messaging and conferencing apps. These altered apps capture communications by grabbing the data out of the app’s UI and sending them to a regime-controlled server, bypassing the encryption. Google signs those altered apps — no different than if the apps came from the original developers — and distributes those altered apps to the designated victims. You can supply your own values for the country and the minority group. There are lots of options to choose from. Technically, the regime-hack scenario could happen today, even with developer-signed APKs. However, in that case, Google cannot sign the altered app versions. So, developers who monitor the signing keys used for their apps would be able to detect the fact that Google is distributing an altered APK. Plus, the risk would be limited to new installs
Re: [guardian-dev] Manipulating App Bundles
On Sun, Jun 21, 2020, at 22:20, John Sullivan wrote:
> Just a quick comment on that last part. It may be worth mentioning for
> a fuller picture that F-Droid signs the builds themselves because they
> build them themselves. They publish all of the source that they are
> building as well as the server software that does the build. Doesn't
> mean things are 100% reproducible, but it might be relevant to mention.
The *intent* is for F-Droid to build the apps themselves solely from the
original sources. With sufficient motivation ("those are lovely kneecaps you
got there -- it would be a pity if we had to break them"), F-Droid could be
convinced to deliver altered apps. And, as with the Google App Bundle scenario,
there is nothing to stop them. That then puts the onus on app developers or the
broader ecosystem to detect this, and I don't know if anyone is looking.
Perhaps people are looking and I just don't know about it -- if you know of
people who are, I'd love to hear about them!
That being said, I replaced the section where I mentioned F-Droid with another
one where I don't mention them directly. A revised post is attached.
Thanks for the feedback!
--
Mark Murphy (a Commons Guy)
https://commonsware.com | https://github.com/commonsguy
https://commonsware.com/blog | https://twitter.com/commonsguyIn Milena Nikolic’s “What’s New in Google Play”
presentation, she said:
As we continue to improve the App Bundle, we expect it to become a requirement for all new apps sometime in 2021.
I have not talked about the App Bundle much, other than privately steering developers
away from it. Technically speaking, I am not opposed to the App Bundle itself. But,
I am vehemently opposed to one “feature” of App Bundles: Google signs them. So,
if Google is going to going to start forcing App Bundles on developers, we need
to focus on the risks inherent in Google signing your apps.
The Folly of Forbearance
In a Medium post,
Wojtek KaliciÅski wrote:
we donât modify and distribute your application code without your knowledge and approval
and:
As stated before, Play will not modify the functionality of your application without your knowledge and approval.
Notably, he used “don’t” and “will not”… as opposed to “can’t” and “cannot”.
Google is perfectly capable of changing anything that
they want in your app. You are what you sign. If Google signs the app, in reality
Google is the developer of the app, controlling what is in it. You just did all the work.
Google readily admits that they modify the app from what you give them as the
App Bundle. Most notably, they subdivide the App Bundle into APKs that allow them to distribute a subset
of your app, stripping out things that the user does not need, based upon
device capability. Mr. KaliciÅski also stated that:
For apps uploaded as app bundles, we will improve this security by introducing what is called a source stamp. This source metadata is inserted into the appâs manifest by bundletool.
So, Google is already modifying your app. They just are claiming that this is all
that they modify of your app.
This is a policy of forbearance. They are capable of doing much more, but they are deciding not to do so at the present time.
However, policies can change, at any time, for any reason, without warning. Or,
as some guy in a dark helmet once said:
I am altering the deal. Pray I don’t alter it any further.
They could add DRM, or automatically collect analytics, or enforce other rules.
The Amazon AppStore for Android does these things,
courtesy of them re-signing your app:
Amazon removes your signature and re-signs your app with an Amazon signature that is unique to you, does not change, and is the same for all apps in your account.
In other words, Amazon is doing today — and has been doing for nearly a decade —
what Google could be doing.
Or, Google could wind up doing things even worse than DRM.
Repression as a Service
Let’s consider a hypothetical scenario:
A country ruled by a repressive regime is oppressing a minority group. The leadership
of that regime tells Google: “In order to do business in our country, you need to
agree to distribute altered versions of apps to users of our choosing. We will supply
you with the altered apps, and we will supply you with the identities or criteria
for choosing the users who should receive these altered apps.” They then supply Google
with the identities of leaders of the minority group, along with altered versions of
Signal, WhatsApp, Zoom, and other end-to-end (E2E) encrypted messaging and
conferencing apps. These altered apps capture communications by grabbing the data
out of the app’s UI and sending them to a regime-controlled server, bypassing
the encryption. Google signs those altered apps — no different than if the
apps came from the original developers — and distributes those altered apps
to the designated victims.
You can supply your own values for the count
[guardian-dev] FYI: Code Transparency
Google finally released some details about their "code transparency" solution for dealing with mandatory App Bundles/Play App Signing for new apps: https://developer.android.com/guide/app-bundle/code-transparency And, FWIW, here are my initial thoughts on the subject: https://commonsware.com/blog/2021/06/29/initial-thoughts-code-transparency.html -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
Re: [guardian-dev] FYI: Code Transparency
On Wed, Jun 30, 2021, at 12:55, Nathan of Guardian wrote:
> Thanks for the always thorough and thoughtful updates and analysis, Mark.
Happy to help, and thanks for the kind words!
> Wouldn't it be possible to build a library that we include in our apps
> that inspects the APK files at runtime on a device, and looks for the
> transparency files in the APK, and even checks the hashes. This could be
> done as a "App Integrity Check" on first run.
The app packager (Google, Amazon) could remove the code that does that check,
or at least nerf it. For example, replace:
if (isMyAppOK()) {
proceed()
} else {
abandonShip()
}
with:
if (true) {
proceed()
} else {
abandonShip()
}
The premise here is that because they have app signing authority, then they
have the technical capability to modify anything that they want in the App
Bundle (APK for Amazon). You start to get into the same sort of arms race that
developers fight and lose with those who try to reverse-engineer apps.
The combination of your proposed library and a robust obfuscation system might
help prevent bulk modification of apps. That starts to impose other limits
(e.g., can't use Crashlytics for bug reporting, because then you're uploading
the de-obfuscation maps to Google). It also won't block a determined attacker
who is going after a few specific apps (e.g., intelligence agency of a country
that strong-arms Google into distributing tampered apps).
I think that the library that you propose will almost "fall out of" work to
create a library for checking the integrity of other apps. Having it probably
won't hurt.
--
Mark Murphy (a Commons Guy)
https://commonsware.com | https://github.com/commonsguy
https://commonsware.com/blog | https://twitter.com/commonsguy
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
Re: [guardian-dev] Android App Bundles
On Thu, Apr 29, 2021, at 08:47, Abel Luck wrote: > There was some discussion about this almost a year ago > https://lists.mayfirst.org/pipermail/guardian-dev/2020-June/thread.html > > However no particular conclusions were reached other than "it sucks." FWIW: https://commonsware.com/blog/2020/09/23/uncomfortable-questions-app-signing.html https://commonsware.com/blog/2020/11/30/initial-responses-uncomfortable-questions.html The initial post definitely struck a nerve in the community -- a surprising number of developers took it upon themselves to pester Google developer relations members on the topic. However, after that late November post, I have not seen much on this subject coming out of Mountain View. I suspect that I'll be writing another post, perhaps tomorrow, pointing out Google I|O sessions that might be of relevance on this subject. -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy ___ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscr...@lists.mayfirst.org
