Declared Origin Policy Manifest Security
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The Same Origin Policy (SOP) in web browsers restricts Rich Internet Applications (RIAs) from accessing necessary web services, causing functional limitations and security vulnerabilities, as it blocks legitimate connections while allowing malicious ones, making it difficult for developers to build web page mash-ups and posing risks if completely removed without replacement.
Innovation Solution
A declared origin policy is implemented, where a manifest lists allowed sites and protocols for an RIA, allowing access only to declared hosts and blocking all other network connections, ensuring secure and unrestricted access to chosen web services by developers.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If Same Origin Policy (SOP) is implemented to block cross-origin access, then security against malicious web pages is improved, but legitimate web services and functional capabilities deteriorate
Solution Approach 1:
The patent changes the security model from automatic origin-based blocking to a whitelist-based approach using manifest files. The security parameter is transformed from restrictive (SOP) to selective (declared origin policy), allowing developers to explicitly declare permitted origins in a manifest file, thereby maintaining security while enabling legitimate cross-origin access.
Solution Approach 2:
The patent introduces a manifest file as an intermediary between the application and the security policy enforcement mechanism. The manifest file serves as a declaration medium that lists permitted origins, acting as a mediator that resolves the conflict between security restrictions and legitimate service access requirements.
2Adaptability or versatility
If Same Origin Policy (SOP) is completely removed to enable unrestricted access, then functional capabilities and web service integration are improved, but security vulnerabilities and malicious access risks worsen
Solution Approach 1:
The patent applies preliminary action by requiring developers to declare permitted origins in advance through a manifest file before the application runs. This pre-declaration approach allows the system to establish security boundaries beforehand, enabling unrestricted access only to explicitly permitted origins while blocking all others, thus preventing security vulnerabilities before they can occur.
3Reliability
If Crossdomain.xml is used to control access, then some cross-origin access control is achieved, but browser technology compatibility and universal applicability deteriorate
Solution Approach 1:
The patent creates a universal security mechanism that works across all browser technologies by using standard web components (HTML, JavaScript, and manifest files) rather than relying on browser-specific implementations like Crossdomain.xml. The declared origin policy is implemented through universal web standards, making it applicable to all browsers and RIA technologies without requiring specific browser support.
4Measurement precision
If manifest-based declared origin policy is implemented, then security control precision and developer flexibility are improved, but system complexity and implementation overhead worsen
Solution Approach 1:
The patent applies self-service by making the security configuration self-contained within the application package itself through the manifest file. The application carries its own security policy declaration, eliminating the need for external configuration files or server-side security setup. This self-service approach reduces system complexity while maintaining precise security control.
Data Source
AI summary
A declared origin policy may be provided. First a plurality of records comprising addresses that an application is allowed to access may be received. The received plurality of records may be placed in a manifest. Then, a request containing an address may be received and compared to the plurality of records in the manifest. Access to the address may be allowed when one of the plurality of records in the manifest matches the address or when an ambiguity is encountered as to whether the one of the plurality of records in the manifest matches the address. Access to the address may be denied when none of the plurality of records in the manifest matches the address. Moreover, any request to change any of the plurality of records in the manifest may be denied when the application is updated, uninstalled, or reinstalled.