Re: Proposal: "private" execution mode

Gili,

can you point to an example of such a process in any other W3C API?

On 11/28/2013 06:27 PM, cowwoc wrote:
> Hi,
>
> I'd like to propose a high-level mechanism for dealing with
> fingerprinting risks. Borrowing from HTTP caching terminology, I
> propose declaring a new Javascript execution mode called "private".
> Code executed in "private" mode would be required to adhere to the
> following restrictions:
>
>   * Any written data would be marked as "private". Data marked as
>     "private" may only be accessed under "private" mode. In other
>     words, privacy is contagious.
>   * Sensitive methods that may be used to leak data outside the UA
>     (e.g. outgoing network requests) MUST throw a permission denied error.
>
> Here is a concrete example of how this may be used:
>
> A user invokes getUserMedia(filter, onSuccess) where filterand
> onSuccess would be supplied by the user. The user invokes the function
> "normal" mode, but filter gets invoked in "private" mode. Here is a
> sample filter:
>
> function filter(candidateDevice)
> {
>   var resolutions = candidateDevice.getResolutions();
>   var idealResolution = {1280, 720};
>   return resolutions.indexOf(idealResolution)!=-1;
> }
>
> In the above function, candidateDevice is marked as "private" by the
> browser before passing it into the function. WebRTC would invoke
> onSuccess in "normal" mode, passing it the first device accepted by
> the filter. *NOTE*: the above definition of getUserMedia() is just an
> example and is not part of this proposal.
>
> There are many ways a browser could implement this proposal. It could
> mark data using a sticky "private" bit (as mentioned above). It could
> "validate" user functions before invoking them, and throw a permission
> denied error if they leak data. Any implementation that prevents
> "private" data from leaking is deemed to be compliant.
>
> While this discussion used the getUserMedia() as an example, I believe
> that this mechanism could be used to tackle fingerprinting risks
> across the entire WebRTC surface. Unlike other proposals, I believe it
> does so without compromising the usability of the WebRTC API and user
> interface.
>
> Let me know what you think.
>
> Gili


-- 
Surveillance is pervasive. Go Dark.