5 ms·

Ironically you have just named the two plugins that have been disabled in my mainstream browser for over a year. Both of those plugins are examples of what no

Ironically you have just named the two plugins that have been disabled in my mainstream browser for over a year. Both of those plugins are examples of what not to do with regards to security, and the first thing I do with new users is train them to surf the web with them off, and switch to a different browser than their main one if they specifically need that functionality. I.e. browse the web with safari (all plugins/java disabled), switch to chrome to watch flash videos (and pray that their sandbox protects you) and switch to Firefox to run your corporate java plugin VPN. Ideally java/flash plugins will die quickly, and we can replace them with browser native technology that we can hold the browser manufacturers accountable for.

frendiversity 14y ago
Browser native functionality wouldn't be cross-platform or even standardized between browsers. What we really need is some kind of native virtual machine that can run cross-platform bytecode in the browser. Someone should make a plugin for this that works with all browsers, it would be genius! </sarcasm>
- deleted 14y ago
  [deleted]
- chii 14y ago
  while you might be sarcastic, this actually does exist: http://jsjvm.org/ http://jsjvm.org/
  - frendiversity 14y ago
    The sarcasm was more referring to the fact that Java (and to some extent Flash with Alchemy VM stuff) is already the best solution for cross-platform native sandboxing in the browser. (If Oracle improves on the updates, that is, and I'm sure they will, they've got a lot on the roadmap for Java.) This is a neat idea though!
    - drivebyacct2 14y ago
      I'd rather trust PNaCl for a portable secure implementation going forward than I would Java Applets experiencing any sort of resurgence.
jtheory 14y ago
I have Java applets that can record and analyze audio and catch MIDI events from any browser including Internet Explorer (any version you're likely to see, really, probably including IE5), as long as Java is installed.... At some point I'm going to have to bite the bullet and switch everything to HTML5, but applets are failing faster than cross-browser native power is advancing, sadly. I'm close to being able to do pitch detection in the browser (it's just a question of getting the code polished & integrated into features, not any tech hurdles; it already works), but that'll be toast for at least a few years if I switch. And I doubt MIDI input will ever be browser-native; I've never even heard whispers about it.... It's a frustrating situation; I just wish it didn't seem like Oracle was so actively hastening the death of the applet.
- chii 14y ago
  perhaps you could do something along the lines of GWT and port your app over to use html5 tech. It was done with quake as a demo, and it works reasonably well.
tsotha 14y ago
>Ideally java/flash plugins will die quickly, and we can replace them with browser native technology that we can hold the browser manufacturers accountable for. I don't know why you would think browser native technology will be any more secure. Java and Flash aren't heavily exploited because they're worse than other products - they're exploited because they're ubiquitous. And it's not like we don't have manufacturers to hold accountable here, whatever that means. Security is hard. It's really, really, really hard to add new functionality without leaving a chink in your security armor. This cycle of 0-day exploits is not going away even when Flash and Java are only discussed in nursing homes.
- drivebyacct2 14y ago
  I am willing to take my chances with the security record and response of the Chrome team over Adobe or Oracle's.
  - tsotha 14y ago
    People used to say the same thing about Java. When you can write a web app for Chrome that can do the same sorts of things applets can do, you're going to see the same sorts of exploits. The problem isn't that the Sun and Oracle people didn't know what they were doing. The problem is your opportunities for security problems scale with the amount of functionality you're delivering.
    - drivebyacct2 14y ago
      You can do almost anything you can do in an applet, now from NaCl/PNaCl or from Javascript (including TCP/UDP sockets, etc) when writing a Chrome CRX or CRX-less webapp that the user opts to install. Maybe you're right, we'll see. That having been said, again, with Chrome's track record, update schedule, update mechanics and more, I'm trusting them a huge factor more than Oracle. Also, keeping in mind that having different implementations across 2-3 major web browsers dampens the effect of having an exploit in one.

frendiversity 14y ago

Browser native functionality wouldn't be cross-platform or even standardized between browsers. What we really need is some kind of native virtual machine that can run cross-platform bytecode in the browser. Someone should make a plugin for this that works with all browsers, it would be genius! </sarcasm>

deleted 14y ago
[deleted]
chii 14y ago
while you might be sarcastic, this actually does exist: http://jsjvm.org/ http://jsjvm.org/
- frendiversity 14y ago
  The sarcasm was more referring to the fact that Java (and to some extent Flash with Alchemy VM stuff) is already the best solution for cross-platform native sandboxing in the browser. (If Oracle improves on the updates, that is, and I'm sure they will, they've got a lot on the roadmap for Java.) This is a neat idea though!
  - drivebyacct2 14y ago
    I'd rather trust PNaCl for a portable secure implementation going forward than I would Java Applets experiencing any sort of resurgence.

jtheory 14y ago

I have Java applets that can record and analyze audio and catch MIDI events from any browser including Internet Explorer (any version you're likely to see, really, probably including IE5), as long as Java is installed.... At some point I'm going to have to bite the bullet and switch everything to HTML5, but applets are failing faster than cross-browser native power is advancing, sadly. I'm close to being able to do pitch detection in the browser (it's just a question of getting the code polished & integrated into features, not any tech hurdles; it already works), but that'll be toast for at least a few years if I switch. And I doubt MIDI input will ever be browser-native; I've never even heard whispers about it.... It's a frustrating situation; I just wish it didn't seem like Oracle was so actively hastening the death of the applet.

chii 14y ago
perhaps you could do something along the lines of GWT and port your app over to use html5 tech. It was done with quake as a demo, and it works reasonably well.

tsotha 14y ago

>Ideally java/flash plugins will die quickly, and we can replace them with browser native technology that we can hold the browser manufacturers accountable for. I don't know why you would think browser native technology will be any more secure. Java and Flash aren't heavily exploited because they're worse than other products - they're exploited because they're ubiquitous. And it's not like we don't have manufacturers to hold accountable here, whatever that means. Security is hard. It's really, really, really hard to add new functionality without leaving a chink in your security armor. This cycle of 0-day exploits is not going away even when Flash and Java are only discussed in nursing homes.

drivebyacct2 14y ago
I am willing to take my chances with the security record and response of the Chrome team over Adobe or Oracle's.
- tsotha 14y ago
  People used to say the same thing about Java. When you can write a web app for Chrome that can do the same sorts of things applets can do, you're going to see the same sorts of exploits. The problem isn't that the Sun and Oracle people didn't know what they were doing. The problem is your opportunities for security problems scale with the amount of functionality you're delivering.
  - drivebyacct2 14y ago
    You can do almost anything you can do in an applet, now from NaCl/PNaCl or from Javascript (including TCP/UDP sockets, etc) when writing a Chrome CRX or CRX-less webapp that the user opts to install. Maybe you're right, we'll see. That having been said, again, with Chrome's track record, update schedule, update mechanics and more, I'm trusting them a huge factor more than Oracle. Also, keeping in mind that having different implementations across 2-3 major web browsers dampens the effect of having an exploit in one.