Network

Web Integrity API: Does Google Want To Introduce Some Kind Of DRM For The Web?

Web Integrity API: Does Google Want To Introduce Some Kind Of DRM For The Web?

Google’s proposal is causing a lot of discussion, which seems to lay the foundations for verifying the software configuration used by each user and offering reliable feedback to software developers. Web Integrity API aims to “get to know” the individual who is using the Web browser, allows you to make sure that they are not a “bot” and that the browser has not been tampered with or modified in an unapproved way.

Google engineers explain that the new APIs would also provide useful data for advertisers who want to better count ad views, to block bot activity on social networks, to enforce intellectual property rights, to make it more secure the financial transactions and avoid the phenomenon of cheating in online video games.

The reference to systems DRM it’s clear. DRM technologies (Digital Rights Management) manage and protect digital rights to content such as music, movies, ebooks, software, and more. Among the most famous and used is Widevine, purchased by Google in 2010. With Web Integrity APIthe company founded by Larry Page and Sergey Brin could impose additional “limits” on the use of its and third-party Web applications.

Four Google developers have been working on the description of the Web Integrity APIs: among them there is also a head of the Chrome Privacy Sandbox team who is responding to the death of tracking cookies (accelerated by the European Privacy Guarantors) by building a platform useful for monitoring user behavior directly at the Web browser level, locally, therefore without relying on cloud services. Part of the mechanism are the Topics API, recently enabled by Google with the release of Chrome 115.

Web Integrity API also uses system signals to “certify” a client platform

Perhaps the most revealing aspect of the explanation of the “aims” of the Web Integrity APIs is the part where Google clarifies that the system relies on “signals” already offered natively by the client device, where available. The Mountain View company points out that the APIs can exploit indicators such as those returned by Play Integrity API su Android e Apple App Attest.

Play Integrity API is a service provided by Google to help Android app developers verify the integrity of their code when running on a user’s device. The service helps developers detect if their app has been compromised or manipulated by malicious software. Think for example of the solutions they seek to bypass security measures.

Previously known as SafetyNet (we also talked about it in the article on AOSP), Play Integrity API allows you to determine if an Android device has been subjected to rooting. After making the device rootdifferent types of applications refuse to work precisely because of the feedback provided by Play Integrity API. Some examples of software that no longer work are banking applications, Google Wallet, online games, Snapchat and some streaming platforms such as Netflix.

App Attest is a technology introduced by Apple to allow iOS app developers to verify that their code works correctly. The service offers a security key specific to the application and allows developers to ensure that their app is not tampered with or tampered with.

An authorization token to access web applications from approved devices

The Web Integrity API they deliver at web applications the ability to access the “authenticity checks” normally available for locally installed apps on mobile devices.

Google’s plan is that, while using a web application, it may require it to pass a test on the guarantees offered by the client in use. Verification is carried out by relying on a third-party server which leads to the creation of a IntegrityToken digitally signed. Exhibiting the token to the web application, you can access the requested content and get a response with all the necessary information.

The choice of Google is already being criticized: that’s why

Google describes its new APIs using a generic approach. In fact, the main actor called to manage “behind the scenes” the operation from the Web Integrity API it would be Google again. The web browser that performs the controls client-side would be Chrome (already started implementing the new APIs…) and the attestation server it would almost certainly belong to the Mountain View company’s infrastructure.

In the documentation of Web Integrity API, Google ensures that the tool now on the launch pad will not be used for non-transparent purposes. A kind of refrain of the historic company motto “Don’t be evil“. The APIs should not be used as an additional signal to perform user fingerprinting activities and should not interfere with browser functionality, including plugins and extensions.

With Mozilla already sidetracking, there are many comments urging Google to shelve the idea of ​​the proposed APIs. Some argue that a project like that of Web Integrity API could pose a serious threat to the Open web as we have conceived it up to now going to interfere with the fundamental freedoms of the user.

The user should be able to evaluate if and when to carry out the root of your Android device, which is also necessary – together with the unlocking of the bootloader – to replace the operating system pre-installed on the smartphone or tablet with a third-party ROM, updated with all the security patches latest.

On this page, Google Chrome users can possibly monitor the progress of the implementation of the Web Integrity API within the web browser.

Leave a Reply

Your email address will not be published. Required fields are marked *