TrustedAuthority

See http://www.codemud.net/~thinker/en/GinGin_CGI.py/show_id_doc/15

This is a proposal of WEB security machanism. This page is for discussions and explanations.

Trusted Authority is a kind of services that users delegate decision making of security to. Users are usually poor on making decisions of security, they even don't understand the questions. UAs asking users for if a web page can use privilege APIs is proved not working and annonying. Delegating decision making to a professional trusted authority would solve/ or mitigate the problem.

How It Works?

After a user download and install an UA, the user install an addon from his Trusted Authority to replace the default one.

When the user visit a service, like Flickr or Intagram, that asks for access of camera. UA would asks the addon provided by the Trusted Authority for the permission of camera API with URLs and digests. The Trusted Authority may allow or deny the API, and may ask a remote server to provide information, and may have a local cache.

After days, the service are compromised and reported. The server of Trusted Authority sends a message to all its addons (clients) to revoke the permissions that had been granted to the service. The UA stops allowing the service to access camera.

The Trusted Authority provides a free service, or a paid service that users are charged to get a better service. The Trusted Authority may check identity of service providers, scan web sites, run static analysis tools, do code review, look at security reports, or make a contract with the service provider to make sure the service follows security policy and rules. There are a lot of strategies and technologies helping Trusted Authorities to make their service better, and they also improves existing tools and invents new tools.

The Trusted Authority addon can notify the user or not. It depends on what kind of user experience the Trusted Authority would like to provide. For power users, they may install a local Trusted Authority to manage all permissions by them-self.

APIs

If a page needs to access some privilege APIs, it needs to request for authorization. The web page asks UA for the authorization, the UA would create a request object to ask Trusted Authority to authorize the access.

API for web pages

The web pages request for the authorization of APIs.

TrustedAuthority.requestAPI(["API-1", "API-2", ...])
  .then(APIs => doSomething())
  .catch(reason => errorHandling());

This API any be called at anywhere and anytime by web pages. For most pages, they may want to call it when they are in loading.

Be emitted by the UA according to meta data/HTTP header of the page?! If UA can do it as early as possible, the web page doesn't need to wait for the authorization. Even the UA has all information required to do authorization before the page being loaded, it makes the Trusted Authority to start loading relative rules from it's server.

Messages

The request created by the UA.

{
  requestID: serial_number,
  APIs: ["name", "of", "APIs"],
  location: "page url", // The page is loaded.
  hash: "SHA512(content of the page)",
  resources: [          // Resources being accessed by the page.
    {location: "URL of the resource 1", hash: "SHA512(content1)", executable: true},
    {location: "URL of the resource 2", hash: "SHA512(content2)", executable: false},
    {....}....]
}

The response replied by the Trusted Authority.

{
  responseID: serial_number, // match requestID
  authorizeLocation: "page url",
  APIs: ["name", "of", "APIs"],
  characteristicResources: [
    {location: "URL of the resource 1", hash: "SHA512(content1)", executable: true},
    ...],
  validBefore: "Valid before the date time"
}

The Trusted Authority can authorize more APIs than requested for performance reason. The UA needs to redo authorization for loading more executable resources (JS code). (How about loading more non-executable resources?)

If the UA keeps the response in a local cache, it should check |validBefore| and make sure all resources in |characteristicResources| having the same hash code/not being changed before grant APIs to the page.

APIs for Trusted Authorities

The Trusted Authority would be run as an addon or service page at local, but talk to remote server hosted by the Trusted Authority.

function handler(request) {
  checkRequstAtRemoteOrLocalDataCache(request);
  if (the request is denied) {
    request.deny();
    return;
  }
  ...
  request.accept({...});
  return;
}
TrustedAuthority.registerAuthorizingHandler(handler);

Remove all authorized requests of given URLs.

TrustedAuthority.revokeAuthorization(["URL", "of", "pages", ....]);

Remove all authorized requests with given prefixes.

TrustedAuthority.reovkePrefixAuthorization(["prefix", "pathes", ...]);

Expose APIs

What APIs should be exposed to WEB with Trusted Authority?

• TCPSocket,
• Device Storage,
• Camera,
• WikiP2P,
• ... more?

Paul suggested to expose only APIs that power users can understand and make decisions.

Responsibility

Trusted Authorities are responsible for checking and making sure the page and resources safe to use the API. A Trusted Authority may review the page and code, backup the site content for later checking, or make a contract with the site to make sure the site following the policy made by the Trusted Authority.

UAs need to make sure all resources in the |characteristicResources| matching what is described.

Users would choose a Trusted Authority trusted by himself. They may paid for the service provided by the Trusted Authority, or for free.

Security

• The Trusted Authority can track activities of users on sites calling privilege APIs.
  • Attack the UA by revoking requests frequently to track how frequent the user visit a site.
  • The UA could monitor how often the Trusted Authority revoking requests and warn the user.
• How do Trusted Authorities make sure that a site is safe?
  • Code review
  • Sign a contract with the sites to make sure the sites following the policy and rules made by the authority.
  • Revoke requests of sites as soon as possible once any malicious behavior is reported.
  • Backup the content of sites for reputation.
• Load more JS code after being authorized.
  • Forbid?
• Should the Trusted Authority grant more APIs than being requested?
  • For performance reason, yes!
  • For security?
• What APIs should be exposed to Trusted Authorities?

Other Problems

• How about the gov. or big players control the web by running trusted authorities?
  • People can still manage permissions by them-self if you are a power user and well knowledge.
  • It is better than market place model, is not controlled by few companies.
  • Users have choices, and it would make a competitions between authorities. (no central point)
  • It is a business, it would encourage Trusted Authorities to improve their process and invent/involve new tools and techniques.