I would _love_ to have a youtube version which just presents a preview pic which is linked to a URL to the flv in question
You do realize that most of YouTube is available in mp4 now, right? I'd actually hate one that only linked to an flv.
I would not have to copy and paste the youtube URL into my own custom script that uses mplayer to play the video outside of the browser window.
Sounds like a job for Javascript.
Specifically, GreaseMonkey. People already generate download links with that, and it wouldn't be terribly difficult to replace the player itself with a download link. The difficult part would be finding an appropriate image.
Or better yet, if it's a format your browser supports, wrap it in a video tag. Then you get right-click and save as.
But you still miss the annotations, if they exist.
it _must not_ be required for a site to work at all.
Which I still strongly disagree with. It again comes down to whether it makes sense or not.
For example: Slashdot absolutely should work without Javascript. All it does is link to other pages and provide a discussion board.
On the other hand...
there are exceptions, but they are very few.
Few, perhaps, but not hard to think of, and I expect to see more in time.
For example, Gmail should work without Javascript, though if I was writing an email client, that wouldn't be a priority for me.
But Gtalk? Google Docs? Sorry, no.
Google Wave is useless without Javascript, yet does provide a very real possibility for replacing... lots of things. Email, IM, document collaboration...
There's also the interesting possibility of combining things like CouchDB with a pure Javascript frontend (plus some static HTML), thus removing the need for any server-side application other than the database itself.
Then there are browser-based games -- arguably, Javascript is a much better vector for these than Flash.
I could go on...
Now, thinking back to YouTube, if I were to publish something on YouTube, I don't think I'd much like the thought of someone watching the raw video, without any of my annotations.
Whoever tagged this story "digitalartisnotfineart" needs a cluebat. I'd like to hear a good argument for that -- ideally one that's not a rehash of the "video games are not art" debate.
Gmail supports imap. Google Calender supports iCal. Google Docs exports natively to OpenDocument. GTalk uses Jabber and Jingle. Google Chrome is open source, as is Google Wave, Android, and plenty of other things I can't remember offhand.
I haven't really seen that much in terms of lock-in from Google, beyond the fact that they often provide the best implementation -- for example, I don't see how you could lock someone into a search engine, yet Google Search remains dominant because it's actually good.
Can you give me your reason for believing Google would lock people in? Any evidence to back that up?
So the solution is, what, <video>? Still requires Javascript to add some features that, if not strictly needed, definitely improve YouTube.
One example: It's possible to link to a specific moment (by timecode) in a YouTube video.
Another example: Aside from subtitles, it's possible for the author to add annotations to a video. This can range from correcting a typo without re-encoding, to adding contextual links to the middle of a video, to correcting one's self without re-encoding and re-shooting the video.
I don't think either of these would be possible without either Javascript, Flash, or some plugin designed specifically for YouTube. I know which I'd prefer.
The fact that you can comment on a video while it's playing (without navigating to another page) is just icing on the cake.
Moral of the story: Just because a technology can be abused is not a reason to avoid the technology, especially because all technology can be abused.
YouTube users can turn off the comments on their own videos.
In other words, it's likely that Microsoft either anticipated that it might be modded down, and they'd rather have no rating than even the possibility of a bad rating...
Or Microsoft noticed the torrent of 0.0 votes and turned off ratings.
So your assertion is that it's not possible to formally prove anything that's Turing-complete?
I'll admit I'm in over my head here, but a quick assumption goes as follows:
I define a Turing-complete, sandboxed language as a set of instructions that can do the following:
Allocate some new storage for itself
Perform some mathematical computation, referring to storage previously allocated
Store arbitrary values (the results of said calculation) in that storage
Call pre-defined routines provided by the sandbox (the DOM, for example)
It seems like it'd be trivial to prove the first three. The fourth, even if unprovable, is also not impossible. Practical examples are any service with a public API. The simple example would be instructions like "display a string" -- to attack that either involves a DoS (trivial for a sandbox to deal with), or a bug in the string handling (Bobby Tables, as trivial to avoid as it is to exploit).
Regardless, the public API need not be even close to Turing-complete -- so your objection is to the possibility of a sandboxed language, with no public API, which cannot be compromised.
The fact that the implementation involves everything running on that turing-complete machine.
To the extent that the implementation of a non-Turing-complete machine involves everything "running" on it as well. There have been vulnerabilities in HTML itself, among other things.
And, for that matter...
has to do with your dumb comment above ("You don't think it's possible to formally prove a sandbox?").
You haven't shown me that it's not possible to formally prove the code that implements a sandbox.
If there were as many holes in JPG rendering libraries as there have been in javascript,
Except this isn't a vulnerability in Javascript, it's a vulnerability in a Javascript application.
then yes disabling images would be an entirely reasonable solution.
Do you really think so?
Because I think the reasonable solution is to fix the libraries.
And I count more than 4 -- there was an exploit involving an image that was actually a Java class file, being executed as a Java program with full local access, as one example.
It's just a finite key space encryption protocol, you need to spend ages and lots of computing power (money) on generating and testing every possible key.
Given the number of possible keys, and the cost of verifying one, that "ages" is likely to be prohibitively high -- as in, "heat-death-of-the-universe".
Goes for coffee, too. I far more frequently drink less than 12 fluid ounces of coffee, and more like 20 fluid ounces of Coke. Or Vault, for that matter.
Oh well, it's probably a good thing, anyway. Caffeine boosts metabolism, which helps with weight loss.
Then what makes the code for implementing a Turing-complete sandbox inherently less secure than the code for a less-than-Turing-complete sandbox?
And what does any of this have to do with the exploit TFA mentions? It wasn't about Javascript escaping the client-side sandbox, nor is there any particular reason for users to enable noscript. It was entirely Reddit's fault.
That always annoys me. No one should be able to steal my session, if it's encrypted (replace with "session cookie" and "https" if we're talking about the Internet) -- if they could, they could probably steal my password, too. If they've got my password, that's a trivial annoyance. And if you're worried about leaving people logged in, add an inactivity timeout.
Or someone would walk away for an hour or two without logging off, and someone else would have to use their computer while they were gone.
Doesn't windows support multiple sessions, these days? Leave their session alone and log in to yours. "Switch user", I think it's called.
They didn't even want the account to automatically log off after work, because it was easier to leave everything up and running overnight and come back to it in the morning...
What about automatically locking, at least?
But yes, I aggree with zippthorne -- get it in writing, especially if you can get them to sign something along the lines of "I understand that this will significantly decrease security, below what many professionals consider to be acceptable."
Catch a coworker with their screen unlocked, get a small bonus.
Get caught that way more than x number of times, get fired. The pink slip is the most effective LART, when it's feasible to use it.
Oh, and make it easy. On KDE, ctrl+alt+l locks my screen. Logging out isn't much harder (win+backspace, then alt+l), but it's not significantly more secure, and it is less convenient (I have to close everything, and I have to watch the logout process to make sure it completes -- lock screen is instantaneous).
Hi there - you must have just popped in from some alternate universe
Yep. It's called Google Chrome -- or, more accurately, the Chromium nightly. Javascript executes quickly, and I don't have to wait for an entire separate page to load. Additionally, if I have to wait, the "submit" button has a countdown timer.
And regardless of speed, it is convenient to have that much more context on the page. For example, right now, I can see your post and mine, and I can expand the parents if I need to. If I was replying from the main discussion, I could scroll up to see the whole discussion. Yes, I know about tabs, but even switching with keyboard shortcuts isn't as nice as being able to actually see a few posts of context as I type.
In this universe, the speed with javascript is noticeably slower - in many cases it's so slow as to be unusable.
the former are "safe" in that it's possible to prove that a particular implementation is free of exploits that would allow running arbitrary code, while Javascript by definition can never be
You don't think it's possible to formally prove a sandbox? Or you only think it's possible to formally prove a sandbox that's not Turing-complete?
Slashdot Mirror
I would _love_ to have a youtube version which just presents a preview pic which is linked to a URL to the flv in question
You do realize that most of YouTube is available in mp4 now, right? I'd actually hate one that only linked to an flv.
I would not have to copy and paste the youtube URL into my own custom script that uses mplayer to play the video outside of the browser window.
Sounds like a job for Javascript.
Specifically, GreaseMonkey. People already generate download links with that, and it wouldn't be terribly difficult to replace the player itself with a download link. The difficult part would be finding an appropriate image.
Or better yet, if it's a format your browser supports, wrap it in a video tag. Then you get right-click and save as.
But you still miss the annotations, if they exist.
it _must not_ be required for a site to work at all.
Which I still strongly disagree with. It again comes down to whether it makes sense or not.
For example: Slashdot absolutely should work without Javascript. All it does is link to other pages and provide a discussion board.
On the other hand...
there are exceptions, but they are very few.
Few, perhaps, but not hard to think of, and I expect to see more in time.
For example, Gmail should work without Javascript, though if I was writing an email client, that wouldn't be a priority for me.
But Gtalk? Google Docs? Sorry, no.
Google Wave is useless without Javascript, yet does provide a very real possibility for replacing... lots of things. Email, IM, document collaboration...
There's also the interesting possibility of combining things like CouchDB with a pure Javascript frontend (plus some static HTML), thus removing the need for any server-side application other than the database itself.
Then there are browser-based games -- arguably, Javascript is a much better vector for these than Flash.
I could go on...
Now, thinking back to YouTube, if I were to publish something on YouTube, I don't think I'd much like the thought of someone watching the raw video, without any of my annotations.
Whoever tagged this story "digitalartisnotfineart" needs a cluebat. I'd like to hear a good argument for that -- ideally one that's not a rehash of the "video games are not art" debate.
Gmail supports imap. Google Calender supports iCal. Google Docs exports natively to OpenDocument. GTalk uses Jabber and Jingle. Google Chrome is open source, as is Google Wave, Android, and plenty of other things I can't remember offhand.
I haven't really seen that much in terms of lock-in from Google, beyond the fact that they often provide the best implementation -- for example, I don't see how you could lock someone into a search engine, yet Google Search remains dominant because it's actually good.
Can you give me your reason for believing Google would lock people in? Any evidence to back that up?
So the solution is, what, <video>? Still requires Javascript to add some features that, if not strictly needed, definitely improve YouTube.
One example: It's possible to link to a specific moment (by timecode) in a YouTube video.
Another example: Aside from subtitles, it's possible for the author to add annotations to a video. This can range from correcting a typo without re-encoding, to adding contextual links to the middle of a video, to correcting one's self without re-encoding and re-shooting the video.
I don't think either of these would be possible without either Javascript, Flash, or some plugin designed specifically for YouTube. I know which I'd prefer.
The fact that you can comment on a video while it's playing (without navigating to another page) is just icing on the cake.
Moral of the story: Just because a technology can be abused is not a reason to avoid the technology, especially because all technology can be abused.
And _every_ site should/must be usable without Javascript/flash/what have you
You forgot: where it makes any sense at all to do so. Show me how YouTube could be usable without Javascript or Flash.
Slashdot is usable without Javascript, it's just much more so with Javascript.
Others need this, like people who have to use screen readers, etc.
I believe Flash does support that now, but really, this is better done with semantic HTML -- Javascript still makes sense.
How would I otherwise say that as concisely, but more correctly?
Whoops, that should read:
YouTube users can disable comments and/or ratings on their own videos.
Funny, but in case anyone doesn't know:
YouTube users can turn off the comments on their own videos.
In other words, it's likely that Microsoft either anticipated that it might be modded down, and they'd rather have no rating than even the possibility of a bad rating...
Or Microsoft noticed the torrent of 0.0 votes and turned off ratings.
So your assertion is that it's not possible to formally prove anything that's Turing-complete?
I'll admit I'm in over my head here, but a quick assumption goes as follows:
I define a Turing-complete, sandboxed language as a set of instructions that can do the following:
It seems like it'd be trivial to prove the first three. The fourth, even if unprovable, is also not impossible. Practical examples are any service with a public API. The simple example would be instructions like "display a string" -- to attack that either involves a DoS (trivial for a sandbox to deal with), or a bug in the string handling (Bobby Tables, as trivial to avoid as it is to exploit).
Regardless, the public API need not be even close to Turing-complete -- so your objection is to the possibility of a sandboxed language, with no public API, which cannot be compromised.
Do I have it right so far?
I wonder why...
The fact that the implementation involves everything running on that turing-complete machine.
To the extent that the implementation of a non-Turing-complete machine involves everything "running" on it as well. There have been vulnerabilities in HTML itself, among other things.
And, for that matter...
has to do with your dumb comment above ("You don't think it's possible to formally prove a sandbox?").
You haven't shown me that it's not possible to formally prove the code that implements a sandbox.
That seems like a really stupid oversight, doesn't it?
For what it's worth, if Linux doesn't already support this, it wouldn't take long to enable.
If there were as many holes in JPG rendering libraries as there have been in javascript,
Except this isn't a vulnerability in Javascript, it's a vulnerability in a Javascript application.
then yes disabling images would be an entirely reasonable solution.
Do you really think so?
Because I think the reasonable solution is to fix the libraries.
And I count more than 4 -- there was an exploit involving an image that was actually a Java class file, being executed as a Java program with full local access, as one example.
It's just a finite key space encryption protocol, you need to spend ages and lots of computing power (money) on generating and testing every possible key.
Given the number of possible keys, and the cost of verifying one, that "ages" is likely to be prohibitively high -- as in, "heat-death-of-the-universe".
Depends on how you take it. ;)
Goes for coffee, too. I far more frequently drink less than 12 fluid ounces of coffee, and more like 20 fluid ounces of Coke. Or Vault, for that matter.
Oh well, it's probably a good thing, anyway. Caffeine boosts metabolism, which helps with weight loss.
The actual code for its implementation? Nope.
Then what makes the code for implementing a Turing-complete sandbox inherently less secure than the code for a less-than-Turing-complete sandbox?
And what does any of this have to do with the exploit TFA mentions? It wasn't about Javascript escaping the client-side sandbox, nor is there any particular reason for users to enable noscript. It was entirely Reddit's fault.
What about the hidden camera until you access the data they want,
Easily countered by only accessing it through a well-shielded device (so no TEMPEST attack) and a wearable computer. Logout is tied to your pulse.
That assumes you need access to it in a public place, or a place where it's feasible for them to put such a hidden camera.
I know I'm stretching, but the more resources you assume the attacker has, the more resources you can throw at the problem.
That always annoys me. No one should be able to steal my session, if it's encrypted (replace with "session cookie" and "https" if we're talking about the Internet) -- if they could, they could probably steal my password, too. If they've got my password, that's a trivial annoyance. And if you're worried about leaving people logged in, add an inactivity timeout.
Or someone would walk away for an hour or two without logging off, and someone else would have to use their computer while they were gone.
Doesn't windows support multiple sessions, these days? Leave their session alone and log in to yours. "Switch user", I think it's called.
They didn't even want the account to automatically log off after work, because it was easier to leave everything up and running overnight and come back to it in the morning...
What about automatically locking, at least?
But yes, I aggree with zippthorne -- get it in writing, especially if you can get them to sign something along the lines of "I understand that this will significantly decrease security, below what many professionals consider to be acceptable."
Catch a coworker with their screen unlocked, get a small bonus.
Get caught that way more than x number of times, get fired. The pink slip is the most effective LART, when it's feasible to use it.
Oh, and make it easy. On KDE, ctrl+alt+l locks my screen. Logging out isn't much harder (win+backspace, then alt+l), but it's not significantly more secure, and it is less convenient (I have to close everything, and I have to watch the logout process to make sure it completes -- lock screen is instantaneous).
Hi there - you must have just popped in from some alternate universe
Yep. It's called Google Chrome -- or, more accurately, the Chromium nightly. Javascript executes quickly, and I don't have to wait for an entire separate page to load. Additionally, if I have to wait, the "submit" button has a countdown timer.
And regardless of speed, it is convenient to have that much more context on the page. For example, right now, I can see your post and mine, and I can expand the parents if I need to. If I was replying from the main discussion, I could scroll up to see the whole discussion. Yes, I know about tabs, but even switching with keyboard shortcuts isn't as nice as being able to actually see a few posts of context as I type.
In this universe, the speed with javascript is noticeably slower - in many cases it's so slow as to be unusable.
Which browser?
the former are "safe" in that it's possible to prove that a particular implementation is free of exploits that would allow running arbitrary code, while Javascript by definition can never be
You don't think it's possible to formally prove a sandbox? Or you only think it's possible to formally prove a sandbox that's not Turing-complete?
Are you sure? Coke is a _lot_ of caffeine, and coffee is less sugar.
It seems to work without Javascript, though it's usually faster with the script.