Confirmed users
503
edits
Annotations: Difference between revisions
m
Reverted edit of Pckqdbhvh, changed back to last version by RyanJones
BrettWilson (talk | contribs) |
m (Reverted edit of Pckqdbhvh, changed back to last version by RyanJones) |
||
| (8 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
== Introduction == | == Introduction == | ||
Annotations are provided by a browser service that can associate arbitrary information with URLs. The goal is to use them for both history and bookmarks. | Annotations are provided by a browser service that can associate arbitrary information with URLs. The goal is to use them for both history and bookmarks. GUI requires close integration with bookmarks to show annotations together with tags. Load the annotations into the sidebar when a URI opened. Flat editable mode in the sidebar would simply the use. | ||
Possible uses: | Possible uses: | ||
* Fav icon | * Fav icon | ||
* Page thumbnail | * Page thumbnail | ||
* Notes | * Notes / Citations | ||
* Persistent storage for Javascript on the page | * Persistent storage for Javascript on the page | ||
* Microformat meta-data, e.g. geo location, dates, events, | |||
The bug for this feature is [https://bugzilla.mozilla.org/show_bug.cgi?id=306640 306640] | |||
== Internal design == | == Internal design == | ||
| Line 20: | Line 23: | ||
* Expiration information | * Expiration information | ||
* Flags (perhaps combined with expiration information) | * Flags (perhaps combined with expiration information) | ||
=== Binary data === | |||
mozStorage can handle binary data. It would be nice to be able to store thumbnails, favicons, and other images as binary data instead of base-64 encoded data URLs. We would have to also store the MIME time for these. | |||
The problem is then how to get the data out of the annotation service and into some UI widget. The data URLs are nice because they can be used in place of "src=" for images. However, is is inefficient to copy around 16K URLs just to display an image. It would be nice if there was a new protocol handler "annot:URL:name" that automatically something from the annotation service. These URLs would have the same privileges as "chrome:" URLs, so would only be accessible to chrome. | |||
=== Expiration === | === Expiration === | ||
| Line 34: | Line 43: | ||
=== Security === | === Security === | ||
Initially, the annotation service will only be available to trusted chrome code. It will be able to read and write any annotation. | |||
If scripts on web pages are allowed to store data, they should only be able to see data that they themselves have written, and not user entered data or service entered data (favicons, etc.). Limiting access to pages on the same path allows some flexibility with different pages from the same service, and should provide minimal opportunity for data leakage. | If scripts on web pages are allowed to store data, they should only be able to see data that they themselves have written, and not user entered data or service entered data (favicons, etc.). Limiting access to pages on the same path allows some flexibility with different pages from the same service, and should provide minimal opportunity for data leakage. | ||
| Line 39: | Line 50: | ||
=== Quota === | === Quota === | ||
If, in the future, limited access to the annotations is given to web apps, they should be restricted in the amount of data that they are allowed to store. We probably want to limit the amount of data per host and possibly also at a finer grained level like pages (as with IE) or paths. | |||
Question: What if a web page wants more storage? Some web services could legitimately need more storage, and provide enough value to the user that they don't care. Should there be a way for the user to specify a web page can add more storage? Here's one possibility: if the page tries to store too much data the write fails and the security bar announces what happened and gives the user the option to increase storage for this page. This would require web pages check for the quota condition, potentially notify the user, and redo the operation if they think it's been fixed. | Question: What if a web page wants more storage? Some web services could legitimately need more storage, and provide enough value to the user that they don't care. Should there be a way for the user to specify a web page can add more storage? Here's one possibility: if the page tries to store too much data the write fails and the security bar announces what happened and gives the user the option to increase storage for this page. This would require web pages check for the quota condition, potentially notify the user, and redo the operation if they think it's been fixed. | ||