4 ms·
@taopao, And for a component to be "trusted" it has to be code that was loaded with the operating system, or in this case, the operating environment (the browse
by EdSharkey 13y ago
@taopao, And for a component to be "trusted" it has to be code that was loaded with the operating system, or in this case, the operating environment (the browser)?
It seems to me that quashing tampering or observing of the trusted component is the lynchpin. In JavaScript, there is no way to access unexposed internals of an IIFE, that seems to me to get us half way there.
I wonder if there could be some way to add a "use trusted" pragma to an IIFE such that the browser would not allow debugging or watching the network traffic of that code? There'd have to be some new way to compare a checksum of the trusted code as well. I suppose that that could suffice in a video watermarking scenario, but Netflix could never watermark each and every video transmitted. I think they partner with some ISP's to cache content near to the users as well, so they're not even responsible for broadcasting the last mile of the video.
- whitehat2k9 13y agoBut it's only a matter of time before someone hacks their browser to ignore those directives.
- EdSharkey 13y agoThis is true, but for the vast majority of consumers would supporting a trusted block of javascript be good enough? All the movie industry wants is to make sure that Joe Sixpack cant get a digital copy of the data stream. I know I am sortof commandeering the word "trusted" for something much weaker than what I think industry wants it to be here, I realize that. Maybe using such a term in a weak solution would satisfy the pointy haired bosses of the world. >:) Seems to me if some rogue binary goes in and tampers with my Firefox or Chrome binary in order to circumvent browser security, then the browsers would know it and fail with an error. Obviously, any browser that builds from source can be directly modified by a developer.