Ricardo Costeira is a Software Engineer from Coimbra, Portugal. For the first time last year, he attended DevFest, the largest developer community-led movement hosted by Google Developer Groups across the world. To celebrate DevFest 2019, we want to share with you Ricardo’s story and how he went from writing code to finding community.
Ricardo (left) and a fellow GDG Lead plan DevFest Coimbra.
1. How did you first hear about DevFest? What inspired you to join?
2. Can you tell us about your first experience at DevFest?
It was exhilarating - out of this world. When I first walked in, everyone talked to me as if we had known each other for years. Big smiles, loud laughs, and deep kindness were all around me. As someone who is relatively shy and a loner by nature, I was stunned when I felt myself saying, "I belong here, I'm home." That very same night, I looked up the next event I could attend. Since then, I have attended 2 other events, signed up for 6 more, and have become a GDG Lead. In other words, I’m hooked.
So how did this all change me? To be honest, DevFest brought forward a shift in my personality. I now want to be part of a community - that is a new feeling in my life.
3. What from DevFest 2018 are you looking forward to seeing again this year?
The booths. DevFest Coimbra has booths where you can talk with different companies. It’s exciting to learn about all the opportunities to grow so close to home. In my case, it was thrilling to see just how quickly Portugal is scaling and how so many companies come to DevFest eager to talk with the best talent. Forming these relationships is what can make the difference when finding the right opportunity for you.
4. Leading up to DevFest 2019, what are you most excited for?
Lighting a spark in new attendees. I recently joined the organizational staff and I’m excited to give new attendees that feeling I had when I first walked into DevFest. I’ve found such meaning in working with my fellow GDG Leads to bring together attendees in a sense of shared awe.
5. Any advice for those attending DevFest 2019?
Just say hi. You will be surprised with how far it will take you. DevFest is not only about the talks or workshops, it’s also about the people. This community knows the extrovert and understands the introvert, and warmly welcomes both. That is to say, no matter who you are or how you code, there is a place for you here.
Want to find a DevFest event near you? Check out devfest.withgoogle.com to join our community, meet other developers and learn about Cloud, Android, Flutter, Machine Learning and more.
Project Strobe was started to help users have control over their data while giving developers more explicit rules of the road to ensure everyone is confident that their data is secure. One result of this effort has been to expand our app verification program to cover more apps and more types of data access. It is important to understand how the process works so that you can optimally build your app and streamline the verification process. Here we walk you through the process of preparing your app for OAuth verification.
The first thing you should do is confirm whether your app needs verification. App verification is only required if you want to launch your app widely to consumer or enterprise users and the app requests sensitive or restricted scopes. Apps that use non-sensitive scopes, are under development, or are built just for your own G Suite users are not required to go through verification. If the app is just for users within your own organization, choose the ‘Internal’ application type to restrict the app to use within your own organization and skip verification.
Once you initiate app verification, it is not easy to make updates to your app's Google API configuration. If you make any changes while in the process, you will need to start over again, so it’s critical that you get your app ready before initiating verification to avoid delays.
The first thing you need to do is look at your code on each platform to determine which OAuth scopes (Google APIs) your service needs. Be sure to do this on every client; we often see that apps will request different scopes on different platforms, and then initiate app verification on a subset of scopes than your clients actually use. Often, you can find the scopes by searching your code for the string “www.googleapis.com/auth”. Not all legacy scopes contain that string so you may also want to find the code related to the Google API library you’re using (on the specific platform) to see what scopes are being requested, or look at our directory of scopes.
Once you have identified all of the scopes that your apps use, you can check to see whether they are sensitive or restricted by going to the Cloud Console (APIs & Services -> Credentials -> OAuth consent screen -> Scopes for Google APIs) and pressing the ‘Add scope’ button. This will bring up the following window:
If the scope has a lock icon, it means that the scope is either sensitive or restricted and that you’ll need to go through app verification before you can widely launch to Google users.
[Note that the tool only lists scopes for APIs that you’ve enabled for your project. If you don’t see a scope listed, you’ll first need to enable the corresponding API for your project from the API Library. The fact that you’re not seeing the scope used in your code may mean that you have clients set up in different projects.]
Apps are reviewed and approved at the project level so you’ll want to make sure that you’ve configured your clients properly before starting app verification. If you have multiple projects, each one will have to independently go through app verification.
When to add multiple clients to a project: You may have multiple clients for your app to support different platforms like Android, Web and iOS. Ideally, all of these clients should be in the same project because it will smooth out the cross-client consent experience. When clients are in the same project, users only need to provide consent to one of the clients. Other clients can automatically get tokens without forcing the user to go through the consent flow for the same requested scopes again. The user is agreeing to share data with your service regardless of which platform they happen to be using and your service terms should be the same across platforms.
When to separate clients into separate projects: Your company may also have multiple apps that you publish to users. You may or may not want to host the clients related to your different apps in the same project. Generally, if the different apps use the same login system, have the same privacy policy and users recognize the brand of the publisher of all the apps, then it makes sense to have all the clients in the same project. For example, if PersonalFinance Corp has accounting, budgeting and tax apps that all share the same login, privacy policy and users recognize the PersonalFinance Corp brand, then it is best to structure those all in the same project. However, if CoolGames publisher has lots of titles that have different login systems and different privacy policies, or users are more familiar with the individual game titles than the CoolGames brand, then you should use separate projects.
Reorganizing projects: It is not possible to move or reorganize clients once they are created. If you want to make changes, you can either choose to create new clients in a centralized project or get each app verified independently. If you create new clients in a centralized project, you’ll update your apps to use the new client and abandon the old clients. The issue you may encounter with this approach is that your app may have to obtain user consent all over again (if the user hasn’t also consented to your other client). Alternately, you can leave your clients in separate projects; however, each project will have to go through app verification independently and users will have to consent to each of your clients individually.
Setting up test vs production projects: For many developers, it is also helpful to have a parallel test project to your production project. This allows you to easily change scopes or other app properties and test behavior without having to go through app verification.
If your app does need to be verified, you’ll want to make sure the information about your project is up-to-date to avoid delay.
As we roll out changes across our API ecosystem, it is important to make sure your projects have up-to-date contact information. We often need to send notifications about changes, and have had developers miss important updates because of incorrect contact information which has resulted in their app being unexpectedly disabled. One way to help ensure your team gets notifications is to create a Google Group that aliases to a stable group within your company (and be sure to configure the group to receive emails from non-members). Another option is to create an Organizational Resource in the Cloud Console so that your client assets can be centrally administered and recovered when owners leave the company. It’s also very good practice to ensure the owners of the Android/iOS/Web clients are also owners or editors of the project. Domain verification is also required for every app, so you will also want to add your DNS administrator to the project so that person can easily go through the process.
To update project owners, use Cloud IAM in the Cloud Console (Cloud Console -> IAM and admin -> IAM).
Branding info includes your app’s name and logo. It is critical that these are accurate because users use these to decide whether they know and trust your app. In the verification process, we will validate that you own the brand and logo and that it matches the information on your web site. If you make changes, your previously approved branding will continue to be shown until the new information can be verified.
You will also need to verify the domain associated with your brand. This is true even if you only have Android/iOS versions of your app because you must have a website to publicly host your privacy policy. You start the domain verification process by linking your domain to your project in the Cloud Console (APIs & Services -> Domain verification). You’ll then need to go to the Search Console to prove that you own and control the domain.
Domain verification is a key security feature for your web clients. If you have web clients in your project, each of those must have their Authorized Redirect URIs or Authorized JavaScript Origins match an already verified domain. This enables us to guarantee that OAuth tokens are only returned to your application.
Since you’ve already identified the scopes that your app uses, you should now check to see if you can change scopes to minimize your data access. Our API User Data Policy requires that you only request information that your app needs and that you’re clear to the user about how you will use it. It’s inappropriate to gain access to Google user data for alternate purposes such as advertising and market research.
In particular, you’ll want to try to avoid the use of restricted scopes. The verification process for restricted scopes can take several weeks longer than sensitive scopes. It also requires significant documentation and may involve a third-party security assessment that you must pay for. Currently, only specific Gmail scopes are restricted, but we have announced that most Drive scopes are also becoming restricted in early 2020.
If your app does need to access a restricted scope, consider architecting your app such that the Google user data is only ever stored client-side on the user’s device (like a contact manager app). Storing data in the cloud or on your own servers will require you to obtain a third-party security assessment (at your expense), and could also result in significant work to resolve any security issues found during the assessment.
Once you’ve decided on the scopes your app will need, make sure that they are registered with your project and reflected in your app’s code. We’ve seen many cases where a developer’s code calls a different set of scopes than those that have been registered in the Cloud Console. If your app does this, your users will see an unverified app error. Many developers request troubleshooting help because their users are unexpectedly seeing these errors even though their app was approved. Inevitably, it is because their code does not match what was verified. Similarly, if you need to add new scopes to your application, you’ll need to get those scopes approved before you launch the functionality into your production app (a test client is going to be essential here).
While you’re thinking about scopes, you should also consider how and when you are asking your users for consent. The best practice is to not request scopes at sign-in, but to use incremental authorization to allow a user to access a particular feature when they want it. This is a great way to build trust because the user interacts in a particular feature, can see the benefit of the feature, and understands why granting a particular permission will make the feature more useful.
Our goal in verifying apps is to ensure that any data users choose to share with third-parties is well-managed and meets users’ expectations about how it will be used. Your privacy policy is your public contract to your users and a critical proof to us that users’ expectations will be met.
You must include a link to your privacy policy on your website. If the domain where you host that policy isn’t verified, we won’t verify your app. If your app is purely mobile, with no server-side component, you will still need a privacy policy, but it may be very simple and describe that your app only stores data on a user’s device.
Google can not provide guidance on your privacy policy, but if your app requests restricted scopes, we will scrutinize your policy to understand how you plan to use that data and ensure that it conforms to our requirements. Make sure you understand the Limited Use requirements, and consult with your legal counsel to ensure that your privacy policy is consistent with the requirements. To ensure clarity in how your app handles email content, we also recommend adding the following statement to your application’s home page: “App’s use of information received from Gmail APIs will adhere to Google's Limited Use Requirements.” This is needed when your privacy policy is not specific in how email content is used.
Once you have your project(s) configured with all the appropriate information, you can submit your app for verification. We have three different types of app verification depending on the scopes you request, each taking a different amount of time to complete. If you start your verification with one set of scopes and later decide you need different scopes, you usually need to finish your existing verification before you can start the process again. This could cause frustration and lengthen your overall verification process.
Brand Verification is our simplest process and validates that your brand name and logo belong to you. It is an optional step if your app is requesting non-sensitive scopes like Google Sign-In and typically takes just 2 to 3 business days. If your app doesn’t go through brand verification, users will only see your domain name listed on the consent page.
Starting in June 2019, we greatly expanded the classification of sensitive scopes and started requiring more extensive verification for new apps that are accessing those scopes. Existing apps that are already accessing sensitive scopes need to go through this verification process in the latter half of 2019.
Sensitive scope verification involves brand and domain validation, checking that the privacy policy is prominently available from your application home page. We also review your app and privacy policy against our API Services: User Data Policy and check for deceptive practices. The privacy policy must disclose the manner in which your application accesses, uses, stores, or shares Google user data. Your use of Google user data must be limited to the practices disclosed in your published privacy policy.
A YouTube or accessible Drive video will also be required to understand how users will experience your request for scopes, showing specifically how they’ll benefit from granting you access. The identity of your app needs to be clear from the video (including the app’s client ID), and you’ll need to highlight the value proposition you communicate to the user before requesting the scopes.
Until verification is completed, users will see an unverified app page when your app requests a scope requiring verification. Up to 100 users may choose to grant access while your app is unverified. After that, users will be blocked from granting access to your app until verification is complete.
Sensitive scope verification usually takes 3 to 5 business days if there aren’t any issues with your app.
Restricted scope verification is a much more involved process. In addition to going through all the steps for a sensitive scope verification, your app will also have a much more rigorous privacy policy review to ensure that your use of Google user data conforms to our Limited Use requirements. Only permitted application types will be considered for access to restricted scopes. Finally, if your app stores data on a server, you will need to pass an annual security assessment.
We do error validation before allowing you to click the ‘Submit for Verification’ button. Here are some common reasons why the button is not clickable:
When you submit your app for verification, you will need to provide a written explanation for why your app needs the requested scopes. This explanation should include the nature of the feature and how the user will benefit from using it. It’s also best to include a link to your YouTube video in the original submission to save some back and forth with the review team.
You’ll also be asked again what email should receive questions and notifications about the verification process. Make sure you provide an address that you pay attention to and can receive emails from outside your domain. Questions will go to the person who initiated verification (not necessarily project owners) and the contact email address provided in the verification form. We’ve seen many requests delayed because the developer hasn’t responded to questions from the verification team.
Apps with sensitive and restricted scopes often need to answer questions from the verification team. If you believe it has taken a long time to get a response from the verification team, you should search your inbox for messages from ‘api-oauth-dev-verification-reply’ to ensure that you haven’t missed anything.
By following these guidelines for submitting your app for verification, you can greatly streamline the process of getting your app approved and released to the Google user community. If you have any follow-up questions, be sure to scan the OAuth API Verification FAQ.
Two years ago, we launched ARCore, our developer platform for building augmented reality (AR) experiences. Since then, we’ve seen developers create thousands of AR apps across Android and iOS that transform the way people play, shop, learn and create together. To enable even more shared cross-platform AR experiences, we’re announcing new updates to ARCore’s Augmented Faces and Cloud Anchors APIs.
Augmented Faces on iOS
Earlier this year, we announced our Augmented Faces API, which offers a high-quality, 468-point 3D mesh that lets users attach fun effects to their faces — all without a depth sensor on their smartphone. With the addition of iOS support rolling out today, developers can now create effects for more than a billion users. We’ve also made the creation process easier for both iOS and Android developers with a new face effects template.
Improvements to Cloud Anchors
Last year, we introduced the Cloud Anchors API, which lets developers create shared AR experiences across Android and iOS. Cloud Anchors let devices create a 3D feature map from visual data onto which anchors can be placed. The anchors are hosted in the cloud so multiple people can use them to enable shared real world experiences. Cloud Anchors power a wide variety of cross-platform apps, like Just a Line, PHAROS AR and Spacecraft AR.
In our latest ARCore update, we’ve made some improvements to the Cloud Anchors API that make hosting and resolving anchors more efficient and robust. This is due to improved anchor creation and visual processing in the cloud. Now, when creating an anchor, more angles across larger areas in the scene can be captured for a more robust 3D feature map. Once the map is created, the visual data used to create the map is deleted and only anchor IDs are shared with other devices to be resolved. Moreover, multiple anchors in the scene can now be resolved simultaneously, reducing the time needed to start a shared AR experience.
These updates to Cloud Anchors are available for developers today.
Persistent Cloud Anchors and Call for Collaborators
As we look to the future, we’re taking steps to expand the scale and timeline of shared AR experiences with persistent Cloud Anchors. We see this as enabling a “save button” for AR, so that digital information overlaid on top of the real world can be experienced at anytime.
Imagine working together on a redesign of your home throughout the year, leaving AR notes for your friends around an amusement park, or hiding AR objects at specific places around the world to be discovered by others.
Persistent Cloud Anchors are powering Mark AR, a social app being developed by Sybo and iDreamSky that lets people create, discover, and share their AR art with friends and followers in real-world locations. With persistent Cloud Anchors, users can continuously return back to their pieces as they create and collaborate over time.
Mark AR is an app that lets people create and discover AR art in real-world locations.
Reliably anchoring AR content for every use case—regardless of surface, distance, and time—pushes the limits of computation and computer vision because the real world is diverse and always changing. By enabling a “save button” for AR, we’re taking an important step toward bridging the digital and physical worlds to expand the ways AR can be useful in our day-to-day lives.
We’re currently looking for more developers to help us explore and test persistent Cloud Anchors in real world apps at scale, before making the feature broadly available. If you’re interested in early access, you can apply here.
This week is a big one for Flutter! Today, at Google Developer Days, our flagship conference for Chinese developers, we used the keynote to announce our latest stable release: Flutter 1.9. This release is our biggest update yet with more than 1,500 PRs from more than 100 contributors. The new features and updates span a wide range, from support for macOS Catalina and iOS 13 to improved tooling support, as well as new Dart language features and new Material widgets.
At the keynote, we also announced a major milestone for Flutter’s web support, with the successful integration of Flutter’s web support into the main Flutter repository, allowing developers to write for mobile, desktop and web with the same codebase. And we showcased Tencent, one of the largest worldwide internet brands, who are using Flutter in a growing number of their mobile apps.
Let’s take a deeper look at this week’s news, starting with what’s new in Flutter 1.9.
As Apple prepares to release Catalina, the latest version of macOS, we’ve worked hard to make sure that Flutter is ready for you to upgrade. We’ve updated the end-to-end tooling experience to ensure it works well on Catalina and with Xcode 11. This includes adding support for the new Xcode build system, enabling 64-bit support throughout the toolchain, and simplifying platform dependencies.
With iOS 13 on the way, we’ve also been working to ensure your Flutter apps look great on the latest iPhone release. Flutter 1.9 includes an implementation of the iOS 13 draggable toolbar, with both long-press and drag-from-right, and supports vibration feedback. Work on iOS dark mode is also well underway with a number of pull requests already merged.
Finally, in the latest development builds, you can now turn on experimental support for Bitcode, which is Apple’s platform-independent intermediate representation of a compiled program. Submitting your app as Bitcode allows Apple to optimize your binary in the future without resubmission, and opens the door to Flutter potentially supporting platforms like watchOS and tvOS that require Bitcode for app submission.
The Material components and features also get an upgrade in Flutter 1.9. Material is one of the world’s leading open-source design systems, providing a comprehensive, flexible set of building blocks for implementing interactive user experiences across many platforms.
In this release, we provide several new widgets including ToggleButtons (left) and ColorFiltered (right).
ToggleButtons
ColorFiltered
The ToggleButtons widget bundles a row of ToggleButton widgets together, often composed of a set of Icon and Text widgets, to form a set of buttons with fully customizable look and behavior. Do you want single selection or multi-select? Do you want to require at least one selection or allow none? Do you want square or rounded edges, thick or thin borders, icons or text, etc? You can see some of these options above on the left and see how they’re implemented in the ToggleButtons sample.
ToggleButton
Icon
Text
As shown in the image above on the right, the ColorFiltered widget allows you to recolor a tree of child widgets just like you can recolor an image using one of several different algorithms (some of which are shown in the example screenshot above). This has many uses, for example, handling color blindness accessibility issues for your users. To see this in action, check out the ColorFiltered sample.
We’ve also added support for 24 new languages, from Afrikaans to Zulu.
The end-to-end developer experience depends not just on the features of Flutter but also on the underlying language itself. As part of the Flutter 1.9 release, we are also releasing Dart 2.5. Dart 2.5 includes a pre-release of Foreign Function Interface (FFI) support, providing native extensions so Dart can call directly into code written in C. It also introduces machine learning-powered code completions for the IDE. You can learn about both of these and more in the Dart 2.5 announcement.
With this release, new projects default to Swift instead of Objective-C and Kotlin instead of Java for iOS and Android projects respectively. Since many packages are written with Swift, making it the default language removes manual work for adding those packages to an app created with the default options. Swift 5 is ABI stable, and thanks to app thinning work Apple has done in recent releases, the Swift dynamic libraries no longer need to be included in the distribution package for iOS 12.2 or greater, reducing the size of Swift applications compared to previous releases.
And as Kotlin is now the default language for new projects in Android Studio, it seems natural to make the language switch for Android also. These options are now the default for both the flutter CLI tool and the IntelliJ/Android Studio and VS Code plugins for Flutter, but you can always switch back to Objective-C or Java if you prefer.
flutter
Additionally, we’ve been working to improve Flutter’s error messages by making them more readable, more concise and more actionable.
The Flutter User Experience team has led the charge on this project; you can read the details in a separate blog post covering the work on structured error display. We’ve just started to apply these new patterns, and you can expect more error messages to take advantage of this work in coming releases.
And finally, we are very happy to announce that the flutter_web repository is deprecated now that web support has been merged into the main flutter repository! What this means is that if you have the latest builds of Flutter from the master or dev channel, you can target the web with the latest experimental version of Flutter by running flutter run -d chrome.
flutter run -d chrome
When you create a project, Flutter now creates a web runner via a minimal web/index.html file that bootstraps your web-compiled Flutter code. With that file in place, you can use the Flutter CLI tool or the IDE plugins to edit and run Flutter apps on the web.
web/index.html
Above is a screenshot of VS Code with web support enabled for Flutter. Notice the web/index.html file, along with the dropdown list allowing you to choose Chrome as your target development device. Support for web output with Flutter is still at an early phase, but this release represents a major step forward towards enabling production support for web development with Flutter.
At the end of July, we announced an early adopter program designed to get a group of select Flutter applications deployed to production on the web over the next six to twelve months. We received over 1,000 submissions to the program. Unfortunately, we don’t have the capacity to support everyone who applied to join the program, but now web support is merged into the Flutter framework, we’re excited that everyone can now experiment with this capability.
Some community experiments have already showcased Flutter’s web output:
Flutter Widget Livebook (left) is built with Flutter for web and shows Flutter widgets running live in your browser. Panache (right) is a tool for creating themes for Flutter which you can then download and drop directly into your code.
Please give this updated experimental support for Flutter on the web a try and let us know if you have any feedback.
We’re thrilled to see continuing fast growth and adoption of for Flutter. Here at Google, hundreds of developers are working on more than twenty projects using Flutter, including some that are released and many that are still in development. At GDD China this week, we highlighted how Tencent, one of the largest internet brands, is using Flutter pervasively for a wide variety of projects:
Switching gears to something just for fun, if you have Google Assistant on your phone or one of the Google Nest Hub devices, try saying “OK Google. Talk to Flutter Widget Quiz.” We loved seeing this community-powered quiz that tests your knowledge of Flutter.
We love the support we’ve received from the developer community, whether in the form of blogs and articles, published apps or issues and code contributions. For more details on upgrading to Flutter 1.9, including details on how to fix any breaking changes that you might experience as you migrate your code, check out the detailed Flutter 1.9 release notes.
There’s a ton for you to try with this release, from trying out the new dart:ffi or ML-based code completion features to experimenting with Flutter for web; from the new support for Catalina and iOS 13 and new ToggleButtons and ColorFilter widgets to testing yourself on your Flutter widget knowledge.
Now that you’ve got Flutter 1.9 in your hands, we’re excited to see what you will build with it!
Whether you're a city planner, a small business owner, or a software developer, gaining useful insights from data can help make services work better and answer important questions. But, without strong privacy protections, you risk losing the trust of your citizens, customers, and users.
Differentially-private data analysis is a principled approach that enables organizations to learn from the majority of their data while simultaneously ensuring that those results do not allow any individual's data to be distinguished or re-identified. This type of analysis can be implemented in a wide variety of ways and for many different purposes. For example, if you are a health researcher, you may want to compare the average amount of time patients remain admitted across various hospitals in order to determine if there are differences in care. Differential privacy is a high-assurance, analytic means of ensuring that use cases like this are addressed in a privacy-preserving manner.
Today, we’re rolling out the open-source version of the differential privacy library that helps power some of Google’s core products. To make the library easy for developers to use, we’re focusing on features that can be particularly difficult to execute from scratch, like automatically calculating bounds on user contributions. It is now freely available to any organization or developer that wants to use it.
A deeper look at the technology
Our open source library was designed to meet the needs of developers. In addition to being freely accessible, we wanted it to be easy to deploy and useful.
Here are some of the key features of the library:
Investing in new privacy technologies
We have driven the research and development of practical, differentially-private techniques since we released RAPPOR to help improve Chrome in 2014, and continue to spearhead their real-world application.
We’ve used differentially private methods to create helpful features in our products, like how busy a business is over the course of a day or how popular a particular restaurant’s dish is in Google Maps, and improve Google Fi.
This year, we’ve announced several open-source, privacy technologies—Tensorflow Privacy, Tensorflow Federated, Private Join and Compute—and today’s launch adds to this growing list. We're excited to make this library broadly available and hope developers will consider leveraging it as they build out their comprehensive data privacy strategies. From medicine, to government, to business, and beyond, it’s our hope that these open-source tools will help produce insights that benefit everyone.
Acknowledgements
Software Engineers: Alain Forget, Bryant Gipson, Celia Zhang, Damien Desfontaines, Daniel Simmons-Marengo, Ian Pudney, Jin Fu, Michael Daub, Priyanka Sehgal, Royce Wilson, William Lam
