Lines Matching full:mechanism
221 The first mechanism is expected to be fairly robust (the implementation is quite simple, based on projection maps, which are highly
223 higher risk of being compromised. Therefore, sensitive information stored in unrestricted columns (for which the first mechanism
247 The <code>URI</code> column is visible to the initiating application, which is a mild security risk. It should be hidden, but the OTA update mechanism relies on it to check duplicate downloads and to display the download that's currently ongoing in the settings app. If another string column was exposed to the initiating applications, the OTA update mechanism could use that one, and <code>URI</code> could then be hidden. For Cupcake, without changing the database schema, the <code>ENTITY</code> column could be re-used as it's currently unused.
274 Getting rid of <code>OTHER_UID</code> would be beneficial for the download manager, but the existing functionality has to be worked around. At this point, the idea that I consider the most likely would be to have checkin and market implement =ContentProvider= wrappers around their downloads, and expose those content providers to whichever app they want, with whichever security mechanism they wish to have.
320 <tr><td > 1003 </td><td > 1.0 <b>YES</b> </td><td > </td><td > Security </td><td > The download manager provides a mechanism that prevents arbitrary applications from accessing meta-data about current and past downloads. </td><td > In 1.0, known holes between apps </td></tr>
332 <tr><td > 2003 </td><td > 1.0 <b>YES</b> </td><td > </td><td > Flaky Downloads </td><td > The download manager has mechanism that prevent excessive retries of downloads that consistently fail or get interrupted. </td><td > </td></tr>
465 <li> Download Manager depends on a mechanism to share files with another app (letting apps access its files, or accessing apps' files).
854 <li> There has to be a mechanism by which old downloads are automatically purged from /cache if there's not enough space .
