This post explores the usage of Feature Policy and Permissions Policy headers on the web. The data shows that 151,159 websites set either header on mobile devices as of June 1, 2022. A more detailed analysis delves into the specific directives used within these policies, examining their prevalence across different website rankings. The queries provided offer a way to analyze the adoption of these important security headers and gain insights into how developers are utilizing them to control browser features and permissions.
This blog post discusses the current state of web API permissions and argues for a more restrictive "off-by-default" approach. It highlights the Principle of Least Privilege and observes that most websites don't utilize Feature Policy or Permissions Policy effectively. The author suggests that instead of asking "what should I turn off?", developers should ask "what should I enable?". The post details the different permission models, the complexity of managing numerous permissions, and the benefits of a deny-all-then-enable approach. It also acknowledges the drawbacks and the need for tooling and guidance to facilitate this shift in thinking. The author concludes by advocating for intentionality in permission management and encouraging a discussion on the topic.
Feature Policy is a new web platform API designed to help developers maintain control over their web app's performance, security, and user experience. It allows developers to define policies that restrict access to certain features or modify the browser's default behavior. Examples include controlling autoplay, access to sensitive APIs, usage of fullscreen, preventing use of outdated APIs, and managing image sizes. Policies act as a contract between the developer and the browser, ensuring the developer's intent is followed even as the project grows and evolves. While adoption is a concern, its potential benefits for performance, security and privacy are substantial, especially if tied to incentives like app store listings.
LocalStorage is a flawed API with poor querying, performance issues, limited storage, inconsistent event handling, and locking problems. Its only advantages are its simple semantics and browser support. Continued use of LocalStorage hinders the development of robust offline and client-side web apps. We should transition to IndexedDB, a superior alternative. I've demonstrated this by converting the BackboneJS TodoMVC example from LocalStorage to IndexedDB using Julien Genestoux's adapter. This involved a few configuration changes, highlighting the ease of adopting IndexedDB, which is our only viable path forward for client-side storage. Let's abandon LocalStorage and embrace IndexedDB to unlock the potential of offline web apps.
