Facebook, Platform Risk, and Eating Your Young – InApps Technology 2022

This week, Facebook held its yearly F8 Developer Conference. Now, if you haven’t heard, Facebook has been in a bit of hot water recently for its general, well, untrustworthiness. Imagine that — the company led by a man quoted deriding his users for trusting him as “dumb f**ks” getting into the muck by again betraying the trust of those selfsame users. All two or so billion of them.

Well, the conference this week took some steps to try to regain some of that trust. According to the SDTimes, the releases announced: “focused on building APIs that create value, giving transparency and control, and focusing on building trust.” Perhaps speaking most directly to its recent issues with securing user data, Facebook is re-opening its app review process, specifically targeting apps that “need access to specialized APIs or extended Login permissions.”

According to Facebook’s post summarizing the conference, “People should be in full control over how they share their information with developers. In 2014, we made significant changes to give people granular controls over the permissions and information they chose to share, and our expectation is that this is reflected in your product experience too.”

It’s almost as if they’re saying, “we gave you the tools to protect yourself four years ago and you failed”.

Well, moving just slightly beyond this aspect of trusting Facebook, John Gruber over at Daring Fireball puts bluntly what might otherwise linger in your mind when developing an app either relying fully on the Facebook platform or even just using the Facebook ID as a primarily login — that is, that any company using Facebook for user ID is foolish.

“It should be illegal, given Facebook’s monopoly status,” Gruber writes. “But every company that has ever trusted Facebook like this should have known better all along.”

See also the tweet cited in Gruber’s post:

https://twitter.com/SirKneeland/status/991373570730147840

Gruber is referring, of course, to Facebook’s announcement of a dating app feature and the heavy reliance of Tinder on using Facebook as its primary login ID.

Ahh, so-called “platform risk,” you rear your ugly head again. Of course, those of you who’ve been around long enough remember the great Twitter API debacle of 2011 — where the company basically shut off access to the many apps that had helped it up until that point and simply built its own versions of those apps it deemed worthy. Perhaps this is just another reminder to beware on what platform you base your product, if any. (Ask most any VC who remains bullish on the great chatbot gold rush of recent years, for example, and they’ll simply pass this off as one of the inherent risks of doing business as a developer, mind you.)

Now, all that said, let’s take a look at all the other announcements made this week by big companies (including Facebook), upon which you might build your next app! (In the same breath, some of these big, evil companies do seem to be doing some big, evil good, developing and open-sourcing tools for the masses…)

But first…

This Week in Programming

• Facebook Announces PyTorch 1.0: Facebook has announced PyTorch 1.0 for both research and production, which is meant to make it easier to get started with AI development. In summary, the open source AI framework “takes the modular, production-oriented capabilities from Caffe2 and ONNX and combines them with PyTorch’s existing flexible, research-focused design to provide a fast, seamless path from research prototyping to production deployment for a broad range of AI projects.” Already, Facebook has used PyTorch to power “many Facebook products and services at scale, including performing 6 billion text translations per day” and the beta will be available in coming months.
• Facebook Open Sources its Go Champion Bot: Facebook’s AI research arm has open sourced ELF OpenGo, the Go-playing AI bot that has defeated world champion professional Go players. “As part of PyTorch,” the company writes in the announcement, “ELF makes it easy for researchers to try different ideas of reinforcement learning with fast and flexible experiments.”
• Swift for TensorFlow Goes Open Source: Continuing with the AI open source theme, Google has announced that Swift for TensorFlow is now open source on GitHub. Swift for TensorFlow, is now an open source project on GitHub. According to ADT Magazine, the project began earlier this year, called “TensorFlow integrated with Swift” (TFiwS) and was later renamed to its current incarnation. The choice of Swift, according to the post, came as a result of the language’s lightweight syntax, modern design, scripting capabilities, inclusion of a interpreter, and its performance in notebook environments. To get started, make sure to check out Google’s “Swift for TensorFlow Design Overview” document on GitHub.

• Google’s Open Source, Sandboxed Container Runtime: Continuing on the Google, open-source route, the company announced its open source sandboxed container runtime, gVisor, noting that, despite the fact that containers have revolutionized “how we develop, package, and deploy applications,” “many security experts don’t recommend them for running untrusted or potentially malicious applications.” In response, the company has produced “gVisor, a new kind of sandbox that helps provide secure isolation for containers, while being more lightweight than a virtual machine (VM).” According to the announcement, gVisor offers “the ease of use and portability of containers, and the resource isolation of VMs.” Check out the repo on GitHub and join the Google group.
• Google’s Open-Source Framework for Confidential Computing: Okay, and one more announcement in the realm of altruistic open source software for the masses, before we move on. This time, it’s Google’s Asylo: an open-source framework for confidential computing that helps developers create applications that run in trusted execution environments (TEEs). “Previously, developing and running applications in a TEE required specialized knowledge and tools,” the company writes. “Asylo makes TEEs much more broadly accessible to the developer community, across a range of hardware — both on-premises and in the cloud.” For more details, check out the post, quick-start guide, documentation, and GitHub repo.
• Google Maps Now With Billing, Support, and Cloud Requirements: Ahh, finally — now we can get back to the business of business. As VentureBeat points out, Google’s new Maps platform arrives with pay-as-you-go billing, free support, and Cloud requirement starting June 11 in a “massive revamp of its Google Maps business.” The Google Maps Platform “promises streamlined API products, a simplified customer experience, a single pricing plan with pay-as-you-go billing, free support, a single console, and new industry solutions” all with one catch — “Starting on June 11, you’ll need a valid API key and a Google Cloud Platform billing account to access the core Google Maps APIs.” The new platform has been designed to work with existing code and combines 18 Google Maps APIs into three products — Maps, Routes, and Places. In its announcement, Google offers a guide for existing users.
• Google’s .app TLD: In one last bit of news from Google (quite a bit has come out from a company having its developer conference next week, huh?) the company has also introduced .app, a more secure home for apps on the web. According to the announcement, the .app TLD is “specifically for apps and app developers, with added security” by requiring HTTPS for all .app domains.

• Stack Overflow for Teams: Perhaps, if your tired of the general toxicity of dealing with Stack Overflow, then this will be for you — Stack Overflow for Teams, where you can get some toxicity directly from your coworkers! (I kid, I kid…) Stack Overflow for Teams “lets you set up a private place on Stack Overflow where you can ask questions that will only be visible to members of your team, company, or organization.” And why not just stick with Slack or creating a company wiki? “Anyone who has used a wiki for this purpose has probably discovered that not very much knowledge actually makes it into the wiki, and what does is not particularly useful, doesn’t get updated, and honestly it just feels like a bunch of homework to write a bunch of wiki documentation about your code when you don’t know if it will ever help anyone. […] And unlike chatrooms, searching actually works. It finds you a question and its answers, not a conversation-captured-in-amber.”