Open Sourcing Tilt Brush
Tilt Brush, Google’s virtual reality painting application, has collaborated with amazing creators over the years, many of whom were part of our Artist in Residence Program. We have tremendous pride for all those collaborations, and the best part has been watching our community learn from each other and develop their abilities over the years.
As we continue to build helpful and immersive AR experiences, we want to continue supporting the artists using Tilt Brush by putting it in your hands. This means open sourcing Tilt Brush, allowing everyone to learn how we built the project, and encouraging them to take it in directions that are near and dear to them.
Tilt Brush launched on the SteamVR platform for the HTC Vive VR headset in April 2016. It went on to help users create their artwork on every major VR platform, including the Oculus Rift, Windows Mixed Reality, Valve Index, PlayStation VR, and Oculus Quest VR headsets. Tilt Brush won dozens of awards, including the Unity Awards 2015: Best VR Experience, the Cannes Lions 2017 Gold Lion in Innovation, and the Oculus Quest award for Best of 2019: VR Creativity Tool of the Year, and was often featured on The Tonight Show Starring Jimmy Fallon. As we look back on Tilt Brush, we’re proud of what this creative application has achieved, and excited for where the community will take it.
What’s Included
The open source archive of the Tilt Brush code can be found at: https://github.com/googlevr/tilt-brush
In order to be able to release the Tilt Brush code as open source, there were a few things we had to change or remove due to licensing restrictions. In almost all cases, we documented the process for adding those features back in our comprehensive build guide. ‘Out of the box’, the code in the archive will compile a working version of Tilt Brush, requiring you only to add the SteamVR Unity SDK.
The currently published version of Tilt Brush will always remain available in digital stores for users with supported VR headsets. If you’re interested in creating your own Tilt Brush experience, please review the build guide and visit our github repo to access the source code.
Cheers, and happy painting from the Tilt Brush team!
By Tim Aidley, Software Engineer, and Jon Corralejo, Program Manager – Tilt Brush
We are excited to announce the GKE CIS 1.1.0 Benchmark InSpec profile under an open source software license is now available on GitHub, which allows you to assess Google Kubernetes Engine (GKE) clusters against security controls recommended by CIS. You can validate the security posture of your GKE clusters using Chef InSpec™ by assessing their compliance against the Center for Internet Security (CIS) 1.1.0 benchmark for GKE.
Validating security compliance of GKE
GKE is a popular platform to run containerized applications. Many organizations have selected GKE for its scalability, self-healing, observability and integrations with other services on Google Cloud. Developer agility is one of the most compelling arguments for moving to a microservices architecture on Kubernetes, introducing configuration changes at a faster pace and demanding security checks as part of the development lifecycle.
Validating the security settings of your GKE cluster is a complex challenge and requires an analysis of multiple layers within your Cloud infrastructure:
GKE is a managed service on GCP, with controls to tweak the cluster’s behaviour which have an impact on its security posture. These Cloud resource configurations can be configured and audited via Infrastructure-as-Code (IaC) frameworks such as Terraform, the gcloud command line or the Google Cloud Console.
Application workloads are deployed on GKE by interacting via the Kubernetes (K8S) API. Kubernetes resources such as pods, deployments and services are often deployed from yaml templates using the command line tool kubectl.
Kubernetes uses configuration files (such as the kube-proxy and kubelet file) typically in yaml format which are stored on the nodes’ file system.
InSpec for auditing GKE
InSpec is a popular DevSecOps framework that checks the configuration state of resources in virtual machines and containers, on Cloud providers such as Google Cloud, AWS, and Microsoft Azure. The InSpec GCP resource pack 1.8 (InSpec-GCP) provides a consistent way to audit GCP resources and can be used to validate the attributes of a GKE cluster against a desired state declared in code. We previously released a blog post on how to validate your Google Cloud resources with InSpec-GCP against compliance profiles such as the CIS 1.1.0 benchmark for GCP.
While you can use the InSpec-GCP resource pack to define the InSpec controls to validate resources against the Google Cloud API, it does not directly allow you to validate configurations of other relevant layers such as Kubernetes resources and config files on the nodes. Luckily, the challenge to audit Kubernetes resources with InSpec has already been solved by the inspec-k8s resource pack. Further, files on nodes can be audited using remote access via SSH. All together, we can validate the security posture of GKE holistically using the inspec-gcp and inspec-k8s resource packs as well as controls using the InSpec file resource executed in an ssh session.
Running the CIS for GKE compliance profile with InSpec
The script requires the cluster name (-c), ssh username (-u), private key file for ssh authentication (-k), cluster region or zone (-r or -z) and InSpec input file as required by the inspec.yml files in each profile (-i). As an example, the following line will run all three profiles to validate the compliance of cluster inspec-cluster in zone us-central1-a:
./run_profiles.sh -c inspec-cluster
-u konrad
-k /home/konrad/.ssh/google_compute_engine
-z us-central1-a
-i inputs.yml
Running InSpec profile inspec-gke-cis-gcp …
Profile: InSpec GKE CIS 1.1 Benchmark (inspec-gke-cis-gcp)
Version: 0.1.0
Target: gcp://<service account used for InSpec>
<lots of InSpec output omitted>
Profile Summary: 16 successful controls, 10 control failures, 2 controls skipped
Test Summary: 18 successful, 11 failures, 2 skipped
Stored report in reports/inspec-gke-cis-gcp_report.
Running InSpec profile inspec-gke-cis-k8s …
Profile: InSpec GKE CIS 1.1 Benchmark (inspec-gke-cis-k8s)
Version: 0.1.0
Target: kubernetes://<IP address of K8S endpoint>:443
<lots of InSpec output omitted>
Profile Summary: 9 successful controls, 1 control failure, 0 controls skipped
Test Summary: 9 successful, 1 failure, 0 skipped
Stored report in reports/inspec-gke-cis-gcp_report.
Running InSpec profile inspec-gke-cis-ssh on node <cluster node 1> …
Profile: InSpec GKE CIS 1.1 Benchmark (inspec-gke-cis-ssh)
Version: 0.1.0
Target: ssh://<username>@<cluster node 1>:22
<lots of InSpec output omitted>
Profile Summary: 10 successful controls, 5 control failures, 1 control skipped
Test Summary: 12 successful, 6 failures, 1 skipped
Stored report in reports/inspec-gke-cis-ssh_<cluster node 1>_report.
Analyze your scan reports
Once the wrapper script has completed successfully you should analyze the JSON or HTML reports to validate the compliance of your GKE cluster. One way to perform the analysis is to upload the collection of JSON reports of a single run from the reports folder to the open source InSpec visualization tool Heimdall Lite (GitHub) by the Mitre Corporation. An example of a compliance dashboard is shown below:
Try it yourself and run the GKE CIS 1.1.0 Benchmark InSpec profile in your Google Cloud environment! Clone the repository and follow the CLI example in the Readme file to run the InSpec profiles against your GKE clusters. We also encourage you to report any issues on GitHub that you may find, suggest additional features and to contribute to the project using pull requests. Also, you can read our previous blog post on using InSpec-GCP for compliance validations of your GCP environment.
A year ago we announced our intention to phase out third-party cookies and replace them with new browser features that are fundamentally more private. Since then, we’ve been working closely with the broader web community, including W3C, to design and implement new privacy-preserving technology, while also preserving the vitality and sustainability of the open web.
Today more than 30 different proposals have been offered by Chrome and others, including many that we believe are key to rendering third-party cookies obsolete. Early test results are also looking promising (see below)!
We are excited to continue testing this foundational tech with the active involvement of ecosystem partners and industry forums – all to move the web forward, together. What follows are key updates since our announcements last January and October.
Early results, and new proposals ready for testing
Five different Privacy Sandbox proposals are available for testing now – or will be very soon – in key areas like fraud detection, the tailoring of content, first-party treatment of a company’s owned and related domains, ads measurement, and a private-by-default way to request browser info. In fact, early testing of the Federated Learning of Cohorts (FloC) algorithm shows that new privacy-preserving ad solutions can be similarly effective to cookie-based approaches. This is great news for users, publishers, and advertisers – all of whom are critical for the future of the web – so we’re excited to carry this work forward.
Another important area of focus is user-facing controls. In particular, it’s clear that people will want to tune whether content is tailored to them (or not) – in addition to keeping their private info private. With the Chrome 90 release in April, we’ll be releasing the first controls for the Privacy Sandbox (first, a simple on/off), and we plan to expand on these controls in future Chrome releases, as more proposals reach the origin trial stage, and we receive more feedback from end users and industry. You can find a full update on all trials on our blog.
Involvement across the ecosystem
It’s great to see companies like Salesforce, White Ops, and Yahoo! JAPAN, starting (or preparing) to test initial solutions like Trust Tokens, First Party Sets, and Conversion Measurement. In fact, all developers have access to public Chrome experiments, and the latest guidance can be found on web.dev, so please do test and share feedback. This type of engagement helps ensure that the various APIs work as expected in real-world scenarios, so the more ecosystem participation, the better!
Building better. Together.
One of the things that makes the web so great is that it’s by and for all of us; this is a special quality amongst today’s platforms, and is definitely worth celebrating! It also creates complexity and trade-offs that we have to manage thoughtfully – and collectively – as we introduce new technology. That’s why we continue to engage in industry forums like the W3C, and are in active discussions with independent authorities – including privacy regulators and the UK’s Competition and Markets Authority – to help identify and shape the best approach for online privacy, and the industry and world as a whole.
So here’s to the users, and coders, and advertisers, and content creators (and so many others) who’ve made, and continue to make the platform what it is today. And here’s to coming together, in service of a more private web.
Posted by Justin Schuh – Director, Chrome Engineering
Custom Tabs is a browser feature, introduced by Chrome, that is now supported by most major browsers on Android. It gives apps more control over their web experience, and makes transitions between native and web content more seamless without having to resort to a WebView. Similar to when using the browser, users frequently want to share the content that is rendered inside the Custom Tabs.
Custom Tabs do not provide a default sharing experience and many apps don’t provide a way for users to share content at all. This results in a poor user experience where users must find the share action from the overflow menu in the browser. This action takes the user outside of the app and opens the link in the browser, resulting in decreased app engagement.
In Chrome 88 we’re running an experiment to automatically add a default share action in certain scenarios. For example, where an app has not specified its own Action Button, we will display one in the top bar. Where a site has specified its own top bar Action Button, a default share action is added to the overflow menu.
A default Action Button that shares the URL is added to the top bar when the application doesn’t provide one.
What do I need to do to enable the new default share action button in?
Nothing! The default Action Button will be automatically added to the application, as long as the application doesn’t set its own. Since this change will happen in the browser, it will be automatically applied to all apps using Custom Tabs.
How can I opt-out from the share icon showing in my App?
|
val customTabsIntent = CustomTabsIntent.Builder() .setShareState(CustomTabsIntent.SHARE_STATE_OFF) .build(); |
Posted by André Bandarra, Developer Relations Engineer and Chirag Desai, Product Manager
Posted by Jochen Eisinger, Engineering Director, Google Chrome
We’ve found that many organizations are challenged by the increasing number of APIs that they make and use. APIs become harder to track, which can lead to duplication rather than reuse. Also, as APIs expand to cover an ever-broadening set of topics, they can proliferate different design styles, at times creating frustrating inefficiencies.
To address this, we’ve designed the Registry API, an experimental approach to organizing information about APIs. The Registry API allows teams to upload and share machine-readable descriptions of APIs that are in use and in development. These descriptions include API specifications in standard formats like OpenAPI, the Google API Discovery Service Format, and the Protocol Buffers Language.
An organized collection of API descriptions can be the foundation for a wide range of tools and services that make APIs better and easier to use.
- Linters verify that APIs follow standard patterns
- Documentation generators provide documentation in consistent, easy-to-read, accessible formats
- Code generators produce API clients and server scaffolding
- Searchable online catalogs make everything easier to find
But perhaps most importantly, bringing everything about APIs together into one place can accelerate the consistency of an API portfolio. With organization-wide visibility, many find they need less explicit governance even as their APIs become more standardized and easy to use.
The Registry API is a gRPC service that is formally described by Protocol Buffers and that closely follows the Google API Design Guidelines at aip.dev. The Registry API description is annotated to support gRPC HTTP/JSON transcoding, which allows it to be automatically published as a JSON REST API using a proxy. Proxies also enable gRPC web, which allows gRPC calls to be directly made from browser-based applications, and the project includes an experimental GraphQL interface.
We’ve released a reference implementation that can be run locally or deployed in a container with Google Cloud Run or other container-based services. It stores data using the Google Cloud Datastore API or a configurable relational interface layer that currently supports PostgreSQL and SQLite.
Following AIP-181, we’ve set the Registry API’s stability level as “alpha,” but our aim is to make it a stable base for API lifecycle applications. We’ve open-sourced our implementation to share progress and gather feedback. Please tell us about your experience if you use it.
By Tim Burks, Tech Lead – Apigee API Lifecycle and Governance
Season of Docs has announced the 2020 program results for standard-length projects. You can view a list of successfully completed technical writing projects on the website along with their final project reports.
During the program, technical writers spend a few months working closely with an open source community. They bring their technical writing expertise to improve the project’s documentation while the open source projects provided mentors to introduce the technical writers to open source tools, workflows, and the project’s technology.
- 80% of the mentors had a positive experience and want to mentor again in future Season of Docs cycles
- 96% of the technical writers had a positive experience
- 96% plan to continue contributing to open source projects
- 94% of the technical writers said that Season of Docs helped improved their knowledge of code and/or open source
Take a look at the list of successful projects to see the wide range of subjects covered!
What is next?
The long-running projects are still in progress and finish in March 2021. Technical writers participating in these long-running projects submit their project reports before March 8th, and the writer and mentor evaluations are due by March 12th. Successfully completed long-running technical writing projects will be published on the results page on March 15, 2021.
By Kassandra Dhillon and Erin McKean, Google Open Source Programs Office
When dealing with large scale Kubernetes deployments, managing configuration and policy is often very complicated. We discussed why Kubernetes’ declarative approach to configuration as data has become the most popular choice for most users a few weeks ago. Today, we will discuss bringing this approach to your MicroK8 deployments using Anthos Config Management.
Anthos Config Management helps you easily create declarative security and operational policies and implement them at scale for your Kubernetes deployments across hybrid and multi-cloud environments. At a high level, you represent the desired state of your deployment as code committed to a central Git repository. Anthos Config Management will ensure the desired state is achieved and also maintained across all your registered clusters.
You can use Anthos Config Management for both your Kubernetes Engine (GKE) clusters as well as on Anthos attached clusters. Anthos attached clusters is a deployment option that extends Anthos’ reach into Kubernetes clusters running in other clouds as well as edge devices and the world of IoT, the Internet of Things. In this blog you will learn by experimenting with attached clusters with MicroK8s, a conformant Kubernetes platform popular in IoT and edge environments.
Consider an organization with a large number of distributed manufacturing facilities or laboratories that use MicroK8s to provide services to IoT devices. In such a deployment, Anthos can help you manage remote clusters directly from the Anthos Console rather than investing engineering resources to build out a multitude of custom tools.
Consider the diagram below.
This diagram shows a set of “N” factory locations each with a MicroK8s cluster supporting IoT devices such as lights, sensors, or even machines. You register each of the MicroK8s clusters in an Anthos environ: a logical collection of Kubernetes clusters. When you want to deploy the application code to the MicroK8s clusters, you commit the code to the repository and Anthos Config Management takes care of the deployment across all locations. In this blog we will show you how you can quickly try this out using a MicroK8s test deployment.
We will use the following Google Cloud services:
- Compute Engine provides an Ubuntu instance for a single-node MicroK8s cluster. Ubuntu will use cloud-init to install MicroK8s and generate shell scripts and other files to save time.
- Cloud Source Repositories will provide the Git-based repository to which we will commit our workload.
- Anthos Config Management will perform the deployment from the repository to the MicroK8s cluster.
Let’s start with a picture
- A workstation instance is created from which Terraform is used to deploy four components: (1) an IAM service account, (2) a Google Compute Engine Instance with MicroK8s using permissions provided by the service account, (3) a Kubernetes configuration repo provided by Cloud Source Repositories, and (4) a public/private key pair.
- The GCE instance will use the service account key to register the MicroK8s cluster with an Anthos environ.
- The public key from the public/ private key pair will be registered to the repository while the private key will be registered with the MicroK8s cluster.
- Anthos Config Management will be configured to point to the repository and branch to poll for updates.
- When a Kubernetes YAML document is pushed to the appropriate branch of the repository, Anthos Config Management will use the private key to connect to the repository, detect that a commit has been made against the branch, fetch the files and apply the document to the MicroK8s cluster.
By Jeff Levine, Customer Engineer – Google Cloud
Criticality of an open source project is difficult to define; what might be a critical dependency for one consumer of open source software may be entirely absent for another. However, arriving at a shared understanding and framework allows us to have productive conversations about our dependencies. Simply put, we define criticality to be the influence and importance of a project.
In order for OpenSSF to fund these critical open source projects, they need to be identified first. For this purpose, we are releasing a new project – “Criticality Score” under the OpenSSF. Criticality score indicates a project’s criticality (a number between 0 and 1) and is derived from various project usage metrics in a fully automated way. Our initial evaluation metrics include a project’s age, number of individual contributors and organizations involved, user involvement (in terms of new issue requests and updates), and a rough estimate of its dependencies using commit mentions. We also provide a way to add your own metric(s). For example, you can add internal project usage data to re-adjust a project’s criticality score for individualized prioritization needs.
Identifying these critical projects is only the first step in making security improvements. OpenSSF is also exploring ways to provide maintainers of these projects with the resources they need. If you’re a maintainer of a critical software package and are interested in getting help, funding, or infrastructure to run your project, reach out to the OpenSSF’s Securing Critical Projects working group here.
By Abhishek Arya, Kim Lewandowski, Dan Lorenc and Julia Ferraioli – Google Open Source
We all benefit from an open web that is secure, powerful, and fast. Over the past year, we’ve focused our efforts on strengthening the web in three areas:
- Rethinking how we can deliver a safe and secure web
- Adding the capabilities you need to build powerful, rich, and diverse applications
- Optimizing for performance, for users and developers alike
This post is a synopsis of the updates we shared during today’s keynote at Chrome Dev Summit.
Rethinking privacy from the ground up
We’ve continued work on the Privacy Sandbox and we are committed to developing an open set of standards that fundamentally enhance privacy on the web. Together with the web community, we’re building new privacy-preserving alternatives to third-party cookies or other cross-site tracking mechanisms. With the Client Hints API, we’re reducing the fingerprinting surface of Chrome, and we have two solutions for you to experiment with via our Chrome origin trials. The Click Conversion Measurement API measures ad conversions without using cross-site identifiers, and the Trust Token APIs help convey trust from one context to another without passive tracking.
More info at web.dev/trust-tokens/
Similarly, the security and privacy of extensions has become of utmost importance with hundreds of millions of people using over 250,000 items in the Chrome Web Store. We believe extensions must be trustworthy by default and it’s why we announced a draft proposal for a number of changes to our extension platform. After incorporating a number of different suggestions from extension developers, we’re ready to launch the stable release of Manifest V3 with the goal of increased security, more control and privacy for users, and improved performance.
With Manifest V3, remote hosted code is no longer permissible to prevent malicious extensions that abuse user privacy and security. Additionally, the new extensions model allows users to withhold sensitive permissions at install time. Lastly, a new approach to background logic with the introduction of service workers for background pages and a new declarative model for extension APIs provides users more consistent performance guarantees. Manifest V3 is now available to experiment with on Chrome 88 beta, with the Chrome Web Store accepting Manifest V3 extensions mid-January when Chrome 88 reaches stable.
Bringing powerful capabilities for advanced apps
Great examples are coming to life from developers who are building new experiences on the web. Gravit Designer makes it easy for users to read and write files with File System Access APIs and allows the use of specialized fonts installed locally with the new Local Font Access API. Adobe has made it easy for users to create stunning visual stories and beautifully designed content with their Spark web app.
Today, we are adding new capabilities for Progress Web Apps (PWAs) to increase their discoverability by being listed in the Google Play Store. In Chrome 86 we gave you the ability to list your PWA in the Play Store using a Trusted Web Activity. We’ve now made it possible for you to start accepting payments using the new Digital Goods API in Chrome 88.
Optimizing for performance
Chrome’s performance—speed and usage of resources like power, memory, or CPU—has always been top of mind so you can deliver the best experience for all our users.
Earlier this year, we made some key improvements to speed with Profile Guided Optimization & Tab throttling and today, we announced a significant reduction of V8’s memory footprint. Apart from making great strides in memory savings through V8 pointer compression, we’ve eliminated parsing pauses entirely by loading a webpage’s JavaScript files in parallel, so scripts can be parsed and compiled and ready to execute as soon as they’re needed by the page.
Since we announced our Web Vitals initiative, they are being increasingly used to measure web page performance. Google Search announced new signals to search ranking will include Core Web Vitals starting in May 2021. In addition to the Chrome User Experience Report, Search Console’s Core Web Vitals report, and many other Google tools, other providers like Cloudflare are surfacing Core Web Vitals as web page performance metrics.
Last summer, we released the web-vitals Javascript library for those sites using Google Analytics. Today we announced the Web Vitals Report, an open source website and tool that lets you query and visualize your Web Vitals metrics data in Google Analytics, enabling you to easily compare performance data across segments.
Finally, we’ve been listening to your feedback and hearing about your difficulties in building web interfaces. We’ve been working to improve the web’s styling capabilities and shipped content-visibility, a CSS feature that significantly improves rendering performance. Look for more updates and tools to improve UI styling, including the announcement of Houdini.how, a set of APIs that makes it easier for you to extend CSS.
A virtual gathering experiment
Chrome Dev Summit has always been about connecting with the community. Although we weren’t able to convene together in person, the Chrome team launched a PWA to bring the best parts of a physical conference — serendipitous conversations, discovering new things, and collecting swag — to life with Chrome Dev Summit Adventure. We can’t wait to hear what you think of this experiment and look forward to chatting with you in real-time.
Learn more
Become part of the community and join a Google Developer Group around the world. Check out the full list of CDS Extended events that brings together regional developer communities to recap the highlights from Chrome Dev Summit 2020 along with live interactive sessions.
Watch the sessions any time on our YouTube channel and for all the latest updates on the web, sign up for the web.dev newsletter.
See you next year!
Posted by Ben Galbraith & Dion Almaer
English
Arabic
Chinese (Simplified)
Chinese (Traditional)
French
Italian
Japanese
Korean
Portuguese
Spanish
Swedish