Confirmed users
398
edits
TrustedAuthority: Difference between revisions
→Other Problems
| (14 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
See http://www.codemud.net/~thinker/en/GinGin_CGI.py/show_id_doc/15 | See http://www.codemud.net/~thinker/en/GinGin_CGI.py/show_id_doc/15 | ||
Trusted Authority is a kind of services that users delegate decision making | 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 == | == APIs == | ||
| Line 53: | Line 66: | ||
} | } | ||
... | ... | ||
request.accept({...}); | |||
return; | return; | ||
} | } | ||
| Line 61: | Line 74: | ||
Remove all authorized requests with given prefixes. | Remove all authorized requests with given prefixes. | ||
TrustedAuthority.reovkePrefixAuthorization(["prefix", "pathes", ...]); | 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 == | == Responsibility == | ||
| Line 83: | Line 106: | ||
** For performance reason, yes! | ** For performance reason, yes! | ||
** For security? | ** 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. | |||