INTERACT FORUM
More => Old Versions => Media Center 15 (Development Ended) => Topic started by: Matt on February 21, 2011, 09:42:39 pm
-
You've probably noticed that IE 9 RC is causing a lot of problems on the main forums. It crashes our software, including versions all the way back to v11. This is because we use the Internet Explorer control to show webpages inside the program. And by default, we show a simple 'Start' webpage on program launch meaning any new user with IE 9 will have a terrible experience.
While lots of software vendors seem to be having trouble with IE 9, we haven't seen or received any feedback from Microsoft on the issue.
As a result, we're considering switching to the Chromium engine for rendering webpages instead of using Internet Explorer:
http://code.google.com/p/chromiumembedded/
We've made enough progress with Chromium Embedded Framework (CEF) to think the actual switch would be relatively easy. The biggest drawback we've seen so far is that the build would get about 6 MB larger.
I'm wondering if anyone here has any experience or advice on this issue.
Thanks.
-
I have no specific help, of course, but I think the 6MB is absolutely worth this change.
PS. Please implement some sort of full-page zoom feature to make the web content in MC more usable from a HTPC.
-
Independance from whatever is on the system=good.
... and may make the switch to linux easier ;) ;D
FWIW... I'm running IE9, and have noticed no issues whatsoever....
-
Wouldn't worry about the size difference at all. I'd personally head in the Gecko direction, but either's good.
IE independance would also make running MC under Wine & similar variants much less of a headache,
-Leezer-
-
For stability and performance reasons I have switched from IE/FireFox to the Google platform as well. IMHO 6MB+ in build size is no issue at all. Stability is what counts. I would whole-heartily support the switch!
-
I concur. The size increase is a small drawback compared to the in-dependency this will provide. MS have not exactly been the best option in browsing anyway. With Chrome it might be faster, more stable and the user can install what ever browser they like. I like it.
-
For stability and performance reasons I have switched from IE/FireFox to the Google platform as well. IMHO 6MB+ in build size is no issue at all. Stability is what counts. I would whole-heartily support the switch!
++
-
Independance from whatever is on the system=good.
... and may make the switch to linux easier ;) ;D
FWIW... I'm running IE9, and have noticed no issues whatsoever....
That's really interesting...
Are you running the RC?
What OS and architecture (32 or 64 bit)?
-
That's really interesting...
Are you running the RC?
What OS and architecture (32 or 64 bit)?
I've been running the beta since it became available, and now the RC. W7-64 on several machines. Haven't tried on 32 bit, as I only have that on netbooks or *gasp* slower (HP tc1100 ;) ) which I don't have the desire to mess around with as much.
[edit] w7-64-enterprise[/edit]
-
I don't think 6 MB larger is an issue.
And Chrome would be much better than IE.
-
Will this impact how webpages are displayed that are added in TheaterView? I use an excellent plugin (Jscript file browser - http://yabb.jriver.com/interact/index.php?topic=51509.0 ) that allows one to use a remote control buttons to browse the files on the computer (including SD card, network shares etc.) and to start playback for a file in MC. I have been using this for a while since MC13 - and it works great with MC16 too after some minor modifications. It currently uses activex, I believe. Will this still continue to run?
Thanks,
Osho
-
It currently uses activex, I believe. Will this still continue to run?
Thanks,
Osho
Probably not. The filebrowser also uses Windows Scripting Host.
-
Probably not. The filebrowser also uses Windows Scripting Host.
in that case, we're gonna need a proper solution to browse removable media in theater view. I, and many others, currently rely on filebroswer for this.
Otherwise, I have no specific issue with chrome being used.
-
in that case, we're gonna need a proper solution to browse removable media in theater view. I, and many others, currently rely on filebroswer for this.
And, not only removable media, also network-mounted samba share drives too..
Thanks,
Osho
-
Regarding the file size, I'd actually prefer to have the installers as small as possible. I guess the "finance manager" at JRiver would also like to minimize the server costs.
Would it be possible to separate the browser code and the MC installer in the build threads? E.g.:
Media Center 16.0.49 (3/10/2011)
http://files.jriver.com/mediacenter/MediaCenter160049minimal.exe (18 MB)
Chromium Browser Code Package 1.0.2 (last updated on 2/25/2011, install if you don't already have this version installed)
http://files.jriver.com/mediacenter/ChromiumPackage102.exe (6MB)
In addition you could provide the full installer (perhaps only in the public release threads):
Media Center 16.0.49 (3/10/2011), Full installer - includes the latest Chromium Browser Code Package
http://files.jriver.com/mediacenter/MediaCenter160049.exe (24 MB)
The official download page would provide only the full installer. When MC checks for updates it could download and install the Chromium part only if necessary.
Naturally the "About Media Center" and "System Info" windows would need to include the Chromium version info.
Of course this would be possible only if the browser code actually can be separate and useful only if the code does not constantly change.
-
Regarding the file size, I'd actually prefer to have the installers as small as possible. I guess the "finance manager" at JRiver would also like to minimize the server costs.
Our experience is that it's bad to ask a user to make any decisions at download time.
We have talked about making the installer smaller and having it download pieces that seldom change. This would mean a fresh install would require an internet connection, which also has drawbacks.
-
Thanks for the suggestion, Alex. We're still thinking about how to handle this. But at 26MB, the size is equal to a few tracks of MP3 music.
Is there a reason that size is important? Bandwidth charges per MB?
-
Otherwise, I have no specific issue with chrome being used.
I take it back! I forgot I have a massive dependency on IE in Theater View. My PVR software exposes a web interface which only works best in IE. I havn't upgraded my HTPC's to IE9 and don't intend to. Unfortunately, this is a deal breaker for me and I can't upgrade my HTPC's beyond MC 15 if this change remains :(
(edit) there may be a work around if I launch IE outside of mc. I'll need to investigate.
-
My PVR software exposes a web interface which only works in IE.
Wow. That's crappy. Which one and why do you use it?
-
I would wholeheartedly support the change even if it were 6GB bigger.
I hate IE and if not for a few web pages that require it and MC it would
not be on my system at all. IMHO Micro$oft should stick with creating the
OS and leave browsers to those who can make a good one.
-
I hope that all other browsers will have compliance. I have invested a lot of time into Firefox, having already migrated from IE, Netscape and Deepnet. I'm not about to change again, especially when I believe FF is one of the very best.
-
I hope that all other browsers will have compliance. I have invested a lot of time into Firefox, having already migrated from IE, Netscape and Deepnet. I'm not about to change again, especially when I believe FF is one of the very best.
I too have a lot invested in Ff as it is my preferred browser but I don't see the correlation since MC has nothing to do with Ff unless you are referring to sites adapting to IE9 and causing problems with Ff. I was going to switch to Google Chrome because it seems faster and more stable until I discovered there was no sidebar for bookmarks or support for the google toolbar. The lack of google toolbar support left me totally flabbergasted since they are the developers of it and it is very useful IMHO. The sidebar I could live without but taking away my google toolbar is like taking away my oxygen. The links it creates in the toolbar when you do a search are irreplaceable to me.
-
I hope that all other browsers will have compliance. I have invested a lot of time into Firefox, having already migrated from IE, Netscape and Deepnet. I'm not about to change again, especially when I believe FF is one of the very best.
It's an internal change that should not affect anything you do with other browsers. You can just think of MC as another browser.
-
Thanks for the suggestion, Alex. We're still thinking about how to handle this. But at 26MB, the size is equal to a few tracks of MP3 music.
Is there a reason that size is important? Bandwidth charges per MB?
I was mainly thinking of your bandwidth charges. Also those who install a new build almost daily might prefer the smaller size.
Assuming the Chromium code would not change often, I would normally only need to download the "minimal" installer when a new build is released.
For example, on this PC my archive of MC installers is 220 files / 3.4 GB... ;)
-
Assuming the Chromium code would not change often,
That's a big assumption to make for a change that would increase user-facing complexity by quite a bit. Despite best efforts, you'd end up with a bunch of new users downloading the wrong installer because they "already have chrome installed" (people don't read very thoroughly).
Chrome evolves quickly. Chromium even more so, and many of those changes are security related.
I was going to switch to Google Chrome because it seems faster and more stable until I discovered there was no sidebar for bookmarks or support for the google toolbar. The lack of google toolbar support left me totally flabbergasted since they are the developers of it and it is very useful IMHO. The sidebar I could live without but taking away my google toolbar is like taking away my oxygen.
I use Firefox as my primary browser as well, but mainly due to the few plugins I've come to rely upon. The Firefox 4 betas though do have dramatically increased, and Chrome-like, speed.
However, the google toolbar thing isn't quite right. The address bar in Chrome acts the same as the Google search box. They just unified it into one bar. You still get the best of the Google Toolbar features in Chrome (http://www.google.com/support/chrome/bin/answer.py?hl=en&answer=160743).
-
However, the google toolbar thing isn't quite right. The address bar in Chrome acts the same as the Google search box. They just unified it into one bar. You still get the best of the Google Toolbar features in Chrome (http://www.google.com/support/chrome/bin/answer.py?hl=en&answer=160743).
I know that the search in Chrome is essentially the same but when you use the bar in Ff it creates links inside the bar for each search string. If you click one of them it goes to that term in the current page. They can be a great time saver when searching through a large page.
(http://www.bowling-info.com/misc/tb.jpg)
-
Big thumbs up to this, switching to a non-IE renderer sounds like a great idea!
-
I know that the search in Chrome is essentially the same but when you use the bar in Ff it creates links inside the bar for each search string. If you click one of them it goes to that term in the current page. They can be a great time saver when searching through a large page.
It doesn't work quite the same way, but Chrome does have a similar feature. From the page I linked to above:
Highlighted search terms
The find bar feature in Google Chrome is similar to the Toolbar "Word find" button. Matches to your find bar search term are automatically highlighted on the page. Plus, you can use the yellow markers on the scrollbar to quickly see where all the matches are located on the page. Google Chrome's find bar doesn't offer several of Toolbar's "Word find" features, such as populating the Toolbar with a button for each word that you type in the search box. Learn more about the Google Chrome find bar.
You're right, though. It doesn't give you the buttons.
I'm against 3rd party browser toolbars on general principle, so I'd never actually use any of them, Google or otherwise.
-
I don't see how switching to another browser internally would fix anything for JRiver except temporarilly. Here are my reasons against:
1. The exact same thing could happen with any other browser. Given the fact that MS has fought tooth and nail to have IE integrated into the OS, I would assume they intend for developers to use it long into the future. I think they would really want to get this issue fixed.
2. IE9 is in beta. RC does not mean final version and between the Beta and the RC there were a tone of fixes. I would expect more before the final version.
3. It exposes a user to more security risks. They may update all the time using Windows Update but how often do most users update MC? How happy would a user be if they got infected via MC? That exposes JRiver as well... Unless you want to get involved in making sure Chromium stayes updated as well... yikes!
4. It is more likely to break other things. I believe users have already mentioned other examples.
5. Some users are reporting no issues with IE9. I'm one of them. So far no issues with MC.
Many users will weigh in here and many will be biased voting for their favorite browser rather than for something that will actuallly improve JRiver. I would give this more consideration. You can also open a support case with MS. I have done so in the past many times and for less than $300 have seen cases move all they up to the developers of a title(Not IE specifically though) and have had bugs fixed with work arounds etc. Their developer support is quite good.
-
gvanbrunt,
You seem to be a proponent for IE. I am by no means trying to tell you what to use but I am just curious to what your logic is when you consider that IE is the slowest, most memory intensive, least compatible and least secure browser on the market today.
-
I am not "a proponent of IE". I am the IT Manager for a corporation and have a lot of experience in both software development and in choice and deployment of browser products. Personally I use IE, FF, and Chrome. They each have their use. I use the right tool for the job at hand. My comments are about what I think is the best choice for MC and it's users, not which browser I use to surf the net. If there are any pros to switching MC's internal engine I'm all ears, but I can't think of any. However as mentioned I can see a lot of downsides.
Also as for you last comment about slowest et al, the gap has narrowed and in some cases may even be faster. Not that that matters in this particular case. Also as for Chrome, I'm most certainly not happy about Googles choice to drop H264 support. Come to think of it, there is reason #5 not for MC to use it... :)
-
We would not make this change if we had a choice, but it is questionable whether MS will fix IE9. They may, but we can't count on it.
-
I think this may be related to the issue you are having:
https://connect.microsoft.com/IE/feedback/details/643966/ie9-rc-crashes-when-calling-idispatch-invoke#details
In case you want to add to that for MS to reproduce and fix the issue.l
-
I think gvanbrunt is making a lot of sence
-
Other than that fact that my last post should have said reason #6 not reason #5. :)
I'm not an MS flunky by any means and there is plenty that I don't like about IE. I have done lots of web development so nobody knows the blues about lack of standards like I do... :) And believe me, I don't want to be the uncool guy backing the "yucky M$ product". But throwing the baby out with the bathwater might be a little premature in this case when a product is still in Beta. It wouldn't be such a big deal if other users were not having it break other functionality.
Call me devils advocate....
-
... throwing the baby out with the bathwater might be a little premature in this case when a product is still in Beta.
It's RC now, not just beta. If Microsoft were telling us that they recognize that it's a problem, we'd not be so concerned, but that's not happening. The next step may just be a release and push to Windows Update.
-
The problem is in the definition of cooperation between two independent software developing companies. The names does not matter, today we (the users) have problems with IE 9RC. Tomorrow, it could be Chromium/Chrome/FF/Opera etc. As long as you depend on some other group developers/architects/designers which have completely different goals as yourself, such problems are inevitable.
And it is definitely not a question of personal taste/like or dislike. My opinion would be leave it as it is right now. It is not the release version, and as far as I could follow the different forums on the net, MC is not the only victim to this mishap.
Before this incident, how many users knew, that they were dependend on IE? And how many years have the engine served, without causing that big a problem?
If IE 9 doesn't work with MC, and MS is ignorant of the problem, then it would be time to change the boat.
-
Call me devils advocate...
Okay. ;)
Isn't rejecting the first implementation of Chromium "throwing out the baby with the bathwater"? The breaking of the FileBrowser plugin has been cited as a compelling reason to not make this change. That makes no sense to me. If Chromium had been used all along, obviously something like FileBrowser would have been created for it. Updates to Chromium could still break that, but then JRiver would likely have the ability to do something about it. And if not, they would probably be in a good position to advise what changes to the plugin are necessary.
Besides, I've always been annoyed an embedded browser behaving exactly like the browser I hate with a passion. Part of my annoyance comes from knowing it's pointless to ask JRiver to do anything about the limitations or issues caused by such a browser. That won't be the case with Chromium. Even if the limitations are the same, at least I'll have someone to complain to. ;)
-
Sorry, but Google is just as nameless and faceless as MS. In fact more so. MS has support that you can call and depend on as a developer. That is not the case with Chrome or other Google products. Read some of their bulletin boards to get the idea. If Chrome breaks, JRiver will have no recourse other than to report the bug same as with MS. How is that any better? If you are suggesting they can grok the source code and fix it themselves I don't see that as very likely given the size of the codebase. And even if they do manage to fix the problem it still has to be submitted to Google and go through their release cycle before it ends up in a public release. Unless they plan on rolling their own forked version. That is a scary thought for sure security wise. If it came to that I would no longer be able to use the product at work.
Before I am yet again be accused of MS bias (kidding), keep in mind I also have a Android Galaxy S and will be switching to a Nexus S as soon as a version is released that supports 850MHz HSPA. I'm speaking from my knowledge as a developer about what product may be best or not. You said it yourself that you are biased and hate IE. I do not hate Chrome. In fact I actually prefer it to IE for regular browsing. My comment stands that many are basing their decision on their like of which browser to surf the web with, not with which browser is the best for MC. They are not the same thing.
#7 I would also like to point out that IE9 is the only browser with Direct X accelerated support for Video etc. I would think that that might be kind of useful to MC... using Chrome means passing on both H264 and accelerated video support. And Adobe is actively working with MS to get Flash working with hardware acceleration.
As for MS suddenly dumping IE9 on Windows Update, MS has Publicly stated that it's release is months off... RC is still beta. Beta is the industry accepted term for software that hasn't been officially released. Just because MS has broken it's beta stage into Beta and RC (actually there is also the CTP stage) does not make it any different. MS's term RC means that it is feature complete but still has bugs. Most of their products go through several RC stages before release. For more information on IE's release plans etc check out the IE blog.
http://blogs.msdn.com/b/ie/archive/2011/02/23/ie9-feedback-platform-previews-through-beta.aspx
Anyhow, I've said my bit as a developer and will leave things to J River to decide what's best for their product. They have done a great job to this point so I won't do more than express my thoughts which I have done. There is also the possibility that maybe there is something they have envisioned with Chrome that would not be possible with IE. I guess time will tell...
P.S. Keep the tomato throwing at the M$ loving guy to a minimum. He would rather spend his time using MS Bob than washing clothes...
-
As for MS suddenly dumping IE9 on Windows Update, MS has Publicly stated that it's release is months off... RC is still beta.
More or less true, but MS proposed an update to RC for one of my machines because I was using the beta. I refused, but most people will probably accept. That's a problem for us.
-
Jim,
I don't want to sound snide, but are you going to support users of Chrome that decide to install from an SVN build rather than public build? That would the equivalent of supporting MS users of beta products. (or almost anyway). Beta products are just that, not for mainstream use and use at your own risk. Most companies refuse to support their product if end users use beta products. I don't see any problem with that. In fact this break of functionality would be a perfect example for you to use in the future for any customers that had an issue with you not supporting beta's of IE etc. MS did not push anyone to install the Beta and only those that did were offered the update...
The bottom line is I think it is a crap shoot about which browser you support in the future. MS has nice long development cycles and IE is very stable in between versions. The same is not true of Chrome. New features and functionality are regularly pushed out. Oh drat. There I go with #9 on my list... :) You may be correct though, that Chrome does turn out to be a windfall in the long run. I just wanted to make sure all the cons were considered prior to doing so. There were not a lot of people speaking out for why not.
Users may now resume throwing vegetables.
-
I don't believe a user installing Chrome will affect MC's support.
-
Is the "MC install of Chrome" going to be seperate from any other install on the computer?
-
Is the "MC install of Chrome" going to be seperate from any other install on the computer?
You misunderstand. It isn't "Chrome". It is "Chromium" which is essentially the "core" of Chrome that is able to be used by third party developers to essentially create another browser (or use browser components within their application). Any application that embeds Chromium will be using its own components and should be independent.
This is different from the way MC used to embed an IE control, which essentially pointed to the IE installation on your computer. One is using internal components (Chromium) and the other is using OS components (IE).
-
I do understand, but there are different ways of accomplishing the use of Chromium. You could install Chrome and "work off the core for that install" or you can install it as a seperate install "local to MC". The risk of the MC seperate install is security. As anyone knows if you don't keep your browser patched you run a very real risk of infection.
If they are using a seperate install I'm worred how often it will be updated. And what about updating it if MC isn't updated etc... With IE it is a shared install and updating IE updates "that part of MC". If MS, Mozilla and Google have problems keeping users updated (I'm not speaking of creating the patches but updating their computers), how is JRiver going to make sure they cover that. That is a pretty tall order for them to fill.
-
off topic....Well maybe on.
Now this is how all features of jriver should be discussed. In depth and informative!
Love reading this stuff.
-
I do understand, but there are different ways of accomplishing the use of Chromium. You could install Chrome and "work off the core for that install" or you can install it as a seperate install "local to MC". The risk of the MC seperate install is security. As anyone knows if you don't keep your browser patched you run a very real risk of infection.
If they are using a seperate install I'm worred how often it will be updated. And what about updating it if MC isn't updated etc... With IE it is a shared install and updating IE updates "that part of MC". If MS, Mozilla and Google have problems keeping users updated (I'm not speaking of creating the patches but updating their computers), how is JRiver going to make sure they cover that. That is a pretty tall order for them to fill.
Okay, cool. I was surprised that you didn't understand it.
I agree that security could be a concern, though I'm not sure how much general-purpose browsing I'll be doing with MC, which does limit the target window somewhat (but certainly not entirely). I imagine they did the integration in a very compartmentalized manner, so that the core Chromium components can be pulled from the source and updated with relative (or complete) ease. But, it would certainly be good to hear that there is some sort of plan in-place to stay on top of it. I guess I just sort-of assumed that they had considered this when they decided to switch to a different rendering engine.
But more importantly... Wouldn't using the shared approach require users to separately install Chrome (or to pack in a separate setup with the installer)? If so, that's not realistic at all (and that's why I didn't even consider it a possibility). Chrome doesn't have anywhere near the installed base that you'd need to require it to be able to use a separate third-party application like MC.
-
Also, I should add...
Constant updates are a mixed bag. They do things like this, for example, and break compatibility with the applications that depend on them. Patches are new code, and new code is, by definition, less tested than existing code. Older codebases can be less secure, but they are also more thoroughly understood. In fact, some patches are implemented in slipshod manners, obviously "under the gun".
I'm certainly no hater of Microsoft. I actually think IE looks like a fairly nice effort, though I don't know if it would get me to switch back (and I'm not huge on their UI design scheme in IE). But, there are also absolutely security downsides to using the IE engine, not the least of which is ActiveX support (which is just one more thing to worry about).
I don't know... I think security-wise it will end up being a wash. But I could be wrong. :-\
-
I do understand, but there are different ways of accomplishing the use of Chromium.
With this response, I don't expect you're going to review your seven objections to Chrome and explain which ones are applicable to Chromium. And here, you seem to be saying if the developers make the wrong choice on alternative implementation strategies, that would be cause for concern. But why should we assume they would make the wrong choice? From what they've said so far, I'm under the impression they would be applying they're own modifications to a Chromium core that is regularly updated. Even if security threats are not addressed as thoroughly or as timely as they are by IE, the exposure is much less. This is an embedded browser that can only be used within a media manager.
-
I realize it is not the reason that is driving the consideration of using chromium, but if doing so would make it possible to use greasemonkey scripts in browser windows within MC, that would be a HUGE win (for me, at least).
-
It doesn't matter how they implement Chromium, all my points still apply. It doesn't matter if it is integrated or not it is susceptible to the same security issues as a full browser. Granted the number of sites may be limited, but that does not mean you are safe. MC is moving toward an agnostic view of all media including internet based ones. It is certainly reasonable that sites available in the near future will include user generated content in addition to the media. If so anyone could post a security compromise that viewers could be infected by. The fact that it is organized crime that is now responsible for most malware on computers makes anyone with money a viable target. They are getting smarter and more agile. I clean computers on a weekly basis at work (about 150 computers) eventhough we have multiple levels of mitigation to prevent infection in the first place. Those are not good odds. It is going to get worse. Having a fully patched browser is no longer just a good idea, it is a necessity. Most infections are "drive bys" these days meaning users are infected simply by visiting a site. They are accomplishing this via Ad's etc so even legitimate sites can be susceptible to this. Most of them use multiple vulnerabilities to target multiple browsers at the same time. The sheer number of computers in Bot-Nets around the globe testifies that users are not savvy enough to protect themselves...
Take this scenario for example. A user buys MC. One year later a new version of MC comes out. The user like many users of MC decides not to upgrade this time. Now their integrated Chromium browser stops getting updates. How many users do we see on the forums still using MC11 or 12? That is not a good thing. If JRiver turns MC into their own browser (which they are doing) they are taking on responsibility for keeping their users safe. Other vendors do and they continue to patch security issues in older products that are no longer the current version for several years. Is JRiver going to do that? Does anyone think that it is OK to surf the net with a browser that has not been patched for a year?
Keep in mind this would be just as big a concern if they took this approch with IE if it were possible (it's not, at least officially). Any browser integrated in this fashion is an issue.
P.S. As a side note, don't be fooled by the FUD that other vendors give you about IE having Active X. That is just the term for MS's plug ins and is no different than that feature in other browsers that use them. The fact that their plug in are COM based makes no differences security wise, it is simply a detail of implementation. Also if you track the number of vulnerabilities patched in browsers over the course of year, MS has a better record than the others. This makes sense since it was the biggest target at one point and now they others are getting more scrutiny. I'm not saying MS is safer, but the once held belief that only MS has security problems is not true. All browsers have known and unpatched vulnurabilities at all times for the last several years. The bad guys are also targeting all the top browsers as well. You would be surprised by the number of users that think they are safe simply because they don't use IE.
-
P.S. As a side note, don't be fooled by the FUD that other vendors give you about IE having Active X. That is just the term for MS's plug ins and is no different than that feature in other browsers that use them.
This isn't quite true, though the differences are probably semantic. ActiveX is more analogous to JavaScript and Java rolled into one, with a bit of Flash ActionScript thrown in for fun. It is similar to the plugin architectures for other browsers, but not exactly the same thing. Code can be downloaded and executed in the browser by simply visiting a website with an embedded ActiveX control. This is not true for the Extension framework built into Firefox, for example, without the extension exploiting another flaw (usually JavaScript or Flash), and by default, there are only a handful of sites that are whitelisted to be allowed to install browser extensions on Firefox of any kind (we're talking 3 or 4 sites directly controlled by Mozilla). Of course, the user can manually override this and whitelist additional sites, but it doesn't just "ask you" to run extension installers all the time when you're just browsing around the web.
JavaScript can do some amazing things, but it is terribly insecure.
Flash can do some amazing things, but it is terribly insecure.
Java can do some amazing things, and it is somewhat better than the previous things mentioned, but it still has serious security problems often.
ActiveX is the same. It is not inherently bad. However, there were some design decisions made (regarding privileges, mainly) that make ActiveX a bit more dangerous in some cases. More importantly, because IE was the dominant browser player for so long, and because it is integrated into Windows, it has become a juicy target. Security isn't about building an impenetrable fortress, which is a fools errand for a connected machine, but about limiting exposure.
ActiveX does not provide me with any user-facing features that are worth the increased risk of exposure, and the single-vendor lock-in required. Therefore, I seek to minimize exposure. This is for the same reason I would never run a browser without a Flash-blocking plugin installed. Flash can be useful, from time to time, but mostly it is used for tracking and ads. It is a high-visibility target with numerous security flaws constantly discovered. If it was not so useful, I would absolutely remove it. Since I cannot remove it without impacting the web's usefulness, I choose to universally disable it and only whitelist items that I need to use. I would prefer to see Flash go away. One less thing to worry about. Limiting exposure.
On the other hand, JavaScript is also a huge problem. However, running with JavaScript disabled, or in whitelist-only mode (via something like NoScript) is far too troublesome to be worth the increased security. Too many sites use JavaScript for way too many useful things. If you have to "expect" to constantly whitelist things to get websites to work properly, you're essentially training yourself to "always agree". There is absolutely nothing more dangerous you can do on your computer than train users, especially unsophisticated users, to "just click agree" without thinking. So, I take reasonable precautions (mainly, keeping my primary browsers up-to-date, since a high percentage of the security fixes from all of the browser vendors are to fix JavaScript exploitations), but I keep JavaScript enabled in my browsers.
I disable JavaScript everywhere else possible, like in PDF readers (why they have that turned on by default is a mystery, but it is evil).
-
Nicely said. My point was that Active X is no more insecure than plug ins in other browsers. In other words IE is not insecure because of Active X. However there are many crappy plug ins created and far too many sites try to install them. That is not a good thing and you are correct that you don't see it in other browsers that often. And sadly as you've mentioned most users just click OK any time something props up... I think we both know the in's and outs of the whole picture, but the "less wordy versions" of the facts we posted left it up to interpretation.
Also as you've stated javascript has had a lot of security problems over the years. And you also mentioned that it is not a very good browsing experience with it off. That points to the need for constant patching for that fact alone.
FYI, one thing to add to the list of dangers is Adobe Reader. That is #1 targeted buggy software right now. Be careful reading PDFs and I would shut off browser integration in FF or IE if you it. That way a PDf can't "open on it's own" inside a web page.
-
Great conversation! :)
Don't install Adobe Acrobat (reader or otherwise). Problem solved. ;) I use FoxIt and keep JavaScript turned off. The VAST majority of the PDF exploits are actually JavaScript privilege escalation flaws.
I did also want to comment on this, briefly...
Nicely said. My point was that Active X is no more insecure than plug ins in other browsers.
I don't think this is quite the case, but not in the way that most people think about security vs. insecurity. Microsoft's ActiveX implementation is less secure than the Firefox extension framework in one important way: Because the default behavior is to "ask the user to allow" any ActiveX control it encounters, no matter what random web site you happen to be on.
Firefox does NOT do this. It default-blocks all extension installation unless you happen to be on a whitelisted site. The only default whitelisted sites in the current version of Firefox are two mozilla-owned domains (I had to look, it is two). The difference is subtle, but I think it is important.
IE encounters an ActiveX control and asks the user: "Hey, there's a control. Do you want to use this contol?"
Firefox encounters an XPI and, unless you are on one of those two domains, it says "This site tried to install an extension and we blocked it. Do this and refresh the page if you really trust these people."
Most unsophisticated users answer yes to version 1, and ignore version 2. Granted, IE is much better now that it co-opted the top-of-the-page style notification (which is more easily ignored than the modal pop-up dialog they used to use).
That said, I agree that there is nothing substantially worse about the security design of the ActiveX system itself, in the current implementations, that makes it any more of a risk than JavaScript or Java or Flash or any other browser extension system. Overall, actually, I'd agree that it is inherently much slightly more robust than JavaScript or Flash. The problem is simply that I need JavaScript and Flash. I don't need ActiveX.
I also wanted to mention...
Granted the number of sites may be limited, but that does not mean you are safe.
You are correct. The only way to ensure network safety is to not play the game and unplug the cord. However, limiting exposure absolutely does make you safer. And that is the name of the game. Oh, and counting "raw" numbers of exploits listed in the "repositories" is a ridiculous PR game that Microsoft likes to play. Talk about FUD. Firefox and Chromium (and Opera) have higher raw counts because they are open source and the code is reviewed in public. IE only gets dinged when either the exploit is independently discovered and someone talks about it, or Microsoft themselves admit it. Severity and susceptibility to unknown zero-day exploits are much more important than trumpeting "634 is a higher number than 187". Security via obscurity is not security at all.
Take this scenario for example. A user buys MC. One year later a new version of MC comes out. The user like many users of MC decides not to upgrade this time. Now their integrated Chromium browser stops getting updates. How many users do we see on the forums still using MC11 or 12? That is not a good thing.
I agree. This is a concern. Once MC16 reaches EOL, we will need a switch turned on that disables the web plugin by default, warns the user to be careful, and allows them to turn it back on manually.
-
You must work in IT too... :)
I agree MS should shut off Active X install of software by default for most sites. No argument there. This fact does make it more of a liability for sure. Even more so now. The bad guys have gotten smart and realise that most corporations don't allow admin privledges to most employees's computers. Now they create per user installs and install scareware after the user clicks OK.... But they never would do that right? :)
I agree that limiting exposure does make you safer as well. I just don't think it's that limited in MC. Right on the default page is a google search box that could take you anywhere. I've used the browser to search for images, videos etc in the past...
I agree that most people need Javascript and Flash. Flash is only really needed for video though. I just hope Google rethinks their decision to drop H264 support so we can get video fixed in the next couple of years instead of 5 years from now. Would be nice to see youtube be able to drop flash...
-
I agree that limiting exposure does make you safer as well. I just don't think it's that limited in MC. Right on the default page is a google search box that could take you anywhere. I've used the browser to search for images, videos etc in the past.
It's limited enough that it more than compensates for delays in security updates. There's no way I can prove that, of course. But you can't prove the contrary. And, more importantly, it seems you're still assuming the developers will not be implementing this properly. If Chrome security updates are implemented in Chromium on a timely basis, and JRiver uses common sense in deciding whether to update its implementation, then I don't see any practical difference in risk. All that's required are suitable warnings to update the software, and probably a mechanism for disabling the browser should it not be updated to whatever point JRiver deems necessary in the circumstances.
-
I agree. This is a concern. Once MC16 reaches EOL, we will need a switch turned on that disables the web plugin by default, warns the user to be careful, and allows them to turn it back on manually.
I was thinking... If J River implemented this really smartly, they wouldn't even really need to do that. I do see a new JRWeb.dll file in my MC16 installation directory, which isn't in my MC15 directory (though this could have been added earlier and I wouldn't have noticed, and it is pretty small).
If the JRWeb.dll, or some other small set of files, does actually contain the chromium components they could actually set up an auto-update scheme that automatically continues updating just these components, from a separate Web Update package that your copy of MC can download from the J River servers. So, when we're in the middle of the cycle for MC17 and MC16 is done, they can keep updating just the web core without mucking with the rest of the installation. This would probably work for a long while, so long as the internal interface to these web components is flexible enough that you can add features without breaking the old interface. And if the updates ever do manage to break older copies of MC (or if you just get tired of supporting the old software - support doesn't last forever) you just flip a switch and "lock" them at the last known-good version (and warn the user, and disable the web components by default).
If I were Jim? I don't know that I'd do that for long. You really want people to upgrade, obviously, so there is that incentive. But more importantly, officially supporting old versions is difficult and "expensive" (it takes away from what you can be doing to improve the product for paying customers). While MC has some browsing features available, it really isn't primarily a browser, so I don't know how big of a deal it is.
I don't know... I keep my start page turned off, and I never visit anything more than the results I get from my "links" (IMDB, AMG, and Wikipedia mostly).
-
I was thinking... If J River implemented this really smartly, they wouldn't even really need to do that.
I have no idea if this is feasible. But I certainly agree it would be reasonable for JRiver to support old versions while that's easy to do, and to stop doing so when it's not.
-
Rick,
I'm not assuming that they will do it wrong. And given the importance of the security I'm not going to assume they are going to do it correctly either. Until we hear from them I'm going to plan for the worst and hope for the best. I like JRiver, its release and development model, it's products and it's support. My comments are not critical of their actions. They are to make sure all the details are explored for this fairly major decision. I'm sure Glynor will agree with me that full disclosure is important when it comes to security. Hidden implantation details are not a good idea if there is risk involved.
-
That sounds like a much different position than...
I don't see how switching to another browser internally would fix anything for JRiver except temporarilly. Here are my reasons against...
Maybe you could comment on ideas for increasing the likelihood of a successful implementation. For example, what do you think of glynor's suggestion?
-
It isn't differnt if you consider the fact that I thought they were talking about a shared Chrome install and not a seperate Chromium only one. A shared install put them in the same boat as with IE. From other posts and the new file Glynor mentioned it is the latter of the two JRiver is doing. Which leads to the security concerns.
As for Glynors ideas they are both excellent. I would also suggest a Chromioum version number be available under the Help->About dialog (or something) so anyone that wants to checks knows which version is being used. In addition it would be good if they posted the Chromium increments in release notes threads... That would give me the warm fuzzys about the move... :)
-
From other posts and the new file Glynor mentioned it is the latter of the two JRiver is doing. Which leads to the security concerns.
I probably didn't understand your original post (http://yabb.jriver.com/interact/index.php?topic=62516.msg419533#msg419533) about the two different ways of implementing Chromium. But it seems clear the extraordinary risk you're talking about is that arising from users not updating the program (and therefore the browser component) regularly. Or, if you prefer, JRiver failing to compel them to do so. That makes me feel much better. For the reasons I've stated, I believe that risk can be easily and appropriately mitigated. Do you disagree, or are you just concerned about measures like those being properly implemented?
-
A dumb question but maybe someone can help me understand...
I know that MC used IE...
I know they switched to Chromium...
I know Chromium is not Chrome, and understand the difference...
But why use embedded technology at all? Why not use the browser the user sets as their default? There must be some reason, therefore my dumb question.
-
great question Magic_Randy, exactly what i was thinking.
-
To clear some things up. The risk is from users not updating MC AND JRiver not updating Chromium on a very regular basis. Both have to happen. To give you and example, if I create a browser using Chromium\Webkit\etc (it's not that hard) and only update it once in a blue moon for security patches etc would you feel safe using it? I know there isn't a security expert on the planet that would say it was OK for you to have it on your computer. That is what JRiver is doing. They are creating their own browser from the guts of another one.
For the reasons I've stated, I believe that risk can be easily and appropriately mitigated.
How likely is it that you will have a problem? That would depend on what you browse for. Since JRiver lets you go anywhere (i.e. google search on home page) that could be anything. That means that JRiver has done nothing to mitigate risk in that respect - it is up to the user not to go anywere that might be an issue. I don't think it is a good idea to let users "mitigate their own risk". Most users are their own worst enemy. Furthermore most infections recently are due to organized crime and not some pimple faced kid in their basement. They are getting smarter everyday and use all kinds of tricks including running infected ads on legitimate sites. You can't be safe by just visiting "good" sites. You need a regularly patched browser. If it isn't updated regularly most users of MC would be oblivious to the fact that they are at risk.
But why use embedded technology at all? Why not use the browser the user sets as their default? There must be some reason, therefore my dumb question.
As for the implementation questions about not using an embedded browser, JRiver uses "hooks" to interact with content on the page. They do this to create customized context menus and to "scrape" content etc. That is not possible unless the browser is embedded. It's not a dumb question at all, sometimes people who do know the details forget that others may not. In fact most people would not know that.
Please don't misunderstand my intentions here. I can tell from some of the posts that some posters may be getting a little angry with me. That always seems to be the case when browser preference is involved. This has nothing to do with that. This is a big change to the core of JRiver and I just want to make sure all the factors are considered. I'm not accusing JRiver of anything, nor am I saying they are doing it wrong. At this point they haven't publicly stated what they are going to do. I'm sure they have read and considered these points and are going to make a good decision. We'll have to wait and see what they say. In the mean time we should keep posting our concerns etc to make sure they are considered.
-
A dumb question but maybe someone can help me understand...
I know that MC used IE...
I know they switched to Chromium...
I know Chromium is not Chrome, and understand the difference...
But why use embedded technology at all? Why not use the browser the user sets as their default? There must be some reason, therefore my dumb question.
To add to gvanbrunts good points.
I'd guess that this is technically impossible. I doubt there is a way to grab the renderer from the users browser of choice and place it into your application.
It would have to open the browser in a separate window which would break the integration aspects of the user experience.
I've never seen that done in another application. I could be wrong however....
-
I trust J River to know what they're doing. They're smarter than me and better developers than me.
As for why an embedded browser is needed in MC. Some of the windows/controls displayed in MC are actually web pages. For example the Performer Store is web content and when you are looking at when you enter the Performer Store is a web page. That's also a page that needs to be integrated within MC for the Performer Store thing to work. You need an embedded browser control to be able to do that. Chromium, IE, something. Having the Performer Store open in an external browser wouldn't work, especially if you're operating MC on your TV with a remote.
Things like the links that go to Google image search, Amazon, Wiki, and other places also open web pages. Those pages could open in an external browser, but again, if you're using MC on a TV with a remote you're going to want those browser pages to open up in MC.
There's other bits of MC that are also web/html pages and need an internal browser of some sort.
Which browser is embedded shouldn't really matter to anyone but the developers. It doesn't matter if it's your favorite browser or not. It just needs to display the stuff it needs to display. Ideally the end user shouldn't even be aware of which browser is working behind the scenes. This shouldn't be a my browser is better than your browser concern. This isn't about being able to load your favorite greasemonkey or adblocker scripts. None of that is relevant.
I don't care which browser is working behind the scenes inside of MC as long as it works and is secure enough that I can click on anything that might be found in a Google image search without worrying about being pwned by an exploit.
-
An alternative suggestion for JRiver is to use the "shared" Chrome install and "use Chromium" from there. If that is possible of course, I have not done any research in that area, but if memory serves I do remember reading about another product doing that. This has the advantage that security is in realm of the user and not Rivers concern at all. They would have to check anytime the browser is used if it is installed and display a page telling them to get Chrome etc. However this is no different than if they wish to add something that "shuts off" the browser (or warn the user) when it becomes outdated enough.
That solves the security question etc, but still leaves the possibility of a Chrome update breaking things just like IE did. In that hopefully rare case JRiver could temporarily substitute for a local copy of Chromium till the issue is resolved.
Thoughts?
Edit: That would also solve the "problem" of adding to the download size etc...
-
To clear some things up. The risk is from users not updating MC AND JRiver not updating Chromium on a very regular basis.
The Internet poses huge risks. Disconnecting from it reduces that risk to zero. So what? Yes, a reputable, fully patched browser reduces risk. So what? It doesn't follow that a doing anything else is an unacceptable risk. Using such a browser without firewall or virus protection would certainly be an unacceptable risk. But if reasonable firewall and virus protection will reduce that risk to an acceptable level, why would they not do so for an embedded browser? Managing risk involves making some reasonable judgments in the balancing of controls and needs. Pulling the plug isn't the answer. Maybe using IE isn't either.
So what would you recommend JRiver do to reduce the risk to an acceptable level? You post as I type...
This has the advantage that security is in realm of the user and not Rivers concern at all.
Why would JRiver seek this "advantage"? Wouldn't be a lot simpler and less a nuisance to users if it were entirely self-contained? Wouldn't updates be based on the current version of Chromium which, in turn, would include the latest critical updates to Chrome?
-
And alternative suggestion for JRiver is to use the "shared" Chrome install and "use Chromium" from there...
That was going to be my next dumb question. Could MC use the Chromium engine that sits under Chrome?
-
Rick,
I'm not really sure the reason for your hostile replies. I have been nothing but polite and tried to express my concerns in a friendly and open manner. In addition I did as you requested and posted some ideas on how implement things safely instead of just expressing my concerns. Is there some reason for your reacton?
-
Please ask the question again and I would be happy to answer it. Also if you could clarify how I have shifted position as I don't see how you see it that way.
-
That was going to be my next dumb question. Could MC use the Chromium engine that sits under Chrome?
That's exactly what they did.
-
That's exactly what they did.
Does this mean that MC could read the libraries of my Chrome install to get Chromium instead of downloading it as part of the MC install?
-
Does this mean that MC could read the libraries of my Chrome install to get Chromium instead of downloading it as part of the MC install?
Yes essentially. It is also the same thing they used to do with IE. It was a "shared install" on the computer and there was nothing they installed in MC's download to use it. The differnece is that the user can potentially remove Chrome and cripple that functionality in MC. That wasn't possible with IE. That makes it more cumbersome for JRiver to implement, but that is only short term. In the long run they won't have to constanly check and update Chromium when they produce a build. They may be able to automate that step in their workflow, so that might also be moot. It would absolve them of any responsibility to update Chromium while still having the same functionality.
On the downside it is possible that Chrome could be updated just like IE was and it would break functionality in MC. However since JRiver could use a local install of Chromium they could download and use that until a fix is available in Chrome.
-
Yes essentially...
All very interesting. I guess we will see what direction JRiver takes.
-
That's exactly what they did.
I actually misunderstood what you meant by your question. I'm not sure if they could do that, but I don't think that they should. Because that would require you to have Chrome installed to be able to use MC, and the best market share numbers for Chrome right now are around 10%. Installed base is certainly higher, but it is nothing like Flash or Java or other frameworks that you can rely on for basic operations.
To be clear, what they actually did is take the open source "core" of Chrome (called Chromium), and integrated it into MC itself. You do not need to have Chrome installed, and even if you do, MC will still use it's own "version" of the browser's core (they will stay independent).
-
My question: What is different about IE9 RC that caused MC to no longer be compatible with it? I appreciate gvanbrunt's comments about security and have to wonder if IE9 RC somehow did not like how MC was accessing the web. I was surprised to see the solution was to use Chromium and avoid IE altogether. This tells me JRiver could not come up with an easy fix, and couldn't anticipate that the final version of IE9 would fix the problem either.
I appreciate that JRiver quickly developed a solution, but am left wondering why this route had to be taken and is there any chance that JRiver reverts back to an IE based browser if Microsoft makes a change in the final IE9 release that would fix the problem.
-
My question: What is different about IE9 RC that caused MC to no longer be compatible with it?
That's a question for Microsoft. We think it's a bug in IE9.
-
While I don't know how this would work as far as security goes, I would LOVE to be able to install Chrome Extensions within the MC browser.
I have most of my links in MC open in the external browser (AllMusic, Google Images, etc.) because I hate seeing all the ads and depend on AdBlock to take care of them. If I could do that within MC it would be great!
-
...but I don't think that they should. Because that would require you to have Chrome installed to be able to use MC...
My guess is that technically they could do it, but you have a good point.
For me, I have multiple browsers (IE, Chrome, FF) anyway. So whatever approach they take works for me. I'm also not really worried about trusting them to keep Chromium current to mitigate security risks.
-
and have to wonder if IE9 RC somehow did not like how MC was accessing the web
I would have to say it is a bug as well. Many developers that integrate IE have this problem since the RC. I don't think JRiver was doing anything wrong that caused the issue.
-
Please don't misunderstand my intentions here. I can tell from some of the posts that some posters may be getting a little angry with me.
Let me start by saying nothing you have said has made me angry and I appreciate your obviously well informed insight as it is quite apparent you know
far more than most when it comes to browser security.
I must say that parts have annoyed me a bit though, this has nothing to do with you personally, it is about society in general.
It seems that nearly all of your posts put all the responsibility on J River and I don't agree. When you go to buy a car does the sales person have to tell
you driving through a 30mph curve at 60 is dangerous and could cause bodily harm or death. If they do need to tell you then they should just take your
keys away. The internet is the same way, if you are stupid enough to browse porn, piracy, or any other questionable site on an embedded browser you
deserve what you get just for acting a fool.
My main point is we as end users need to be just as or more responsible than the provider. In general end users are not and are often quick to point the
finger even when it was their own foolish behavior that caused the mishap. Some people don't learn until it happens to them so I say let them learn. I know
that is harsh but there are times that it takes a stern outlook to make things happen.
Why do they call it common sense when it is not common? ;)
-
I do think it's highly optimistic for people to think that MS will "fix" the problem with IE on the basis that a few people (in relative terms) using a non MS product are experiencing problems with it. When did MS ever do that? It is a shame that JR cannot be complete independent of all browser engines because the chances are that this sort of thing will most likely re-occur in the future, be it IE , Chrome or A.N.Other browser.
-
It seems that nearly all of your posts put all the responsibility on J River and I don't agree.
I agree 100%. I hate the fact that the society and the courts seem to thing that people are not responsible for their own actions. There are drunk drivers suing bars, etc. I don't agree with that. However the courts seem to. In the case of JRiver if they create a browser, they must do what is reasonable to keep users safe. I think that most courts would look at what other browsers vendors do and compare them to that. If it is commone practice for browser for other vendors to something, they have to as well or the run the risk of a lawsuit. I don't want this to deteriorate into discussion about the law etc, but there is the possibility of this sort of thing. JRiver might be legally responsible to that point and that is why I bring it up.
If that is the case and they are to match what the other vendors do, they must take reasonable precautions to make sure users are patched etc. This has already been covered and I'm pretty sure JRiver probably has that on their to-do list anyway. I was just showing some of the ramifications were such as users of older versions of the product etc to make sure JRiver had thought of them. It has been mentioned and now we have to wait and see what they decide to do. Either way it isn't going to affect me much as I take a lot of precautions anyway.
I do disagree with you that the only way you will get infected is by browsing porn, warez etc. It has already happened that criminals have bought ads on mainstream sites and infected thousands of users that way. The risk of infection via legitimate sites has been growing over the last two years. The only protection you have is a properly patched browser. Unfortunately that isn't enough either as they have turned to 0-day exploits (unpatched) while vendors are fixing them. That currently takes months and needs to change. The best protection is as you've said, use common sense. Also don't browse with administrative privileges. Run with a regular user account and keep the administrator account for installing software etc. It is a pain but it is what I do because I know the risks.
You are 100% correct that users need to be more responsible than vendors. They need to depend on themselves because vendors can not keep up with the threats out there. The main reason I bring all this up is that out of 150 or so computers at work we see 1 or 2 a week that are infected. Users do not have admin privileges, there are multiple levels of virus protection. Browsers and OS's are patched on a weekly basis (or more), and they are using only work related sites, etc. In addition the users are engineers etc, so they they tend to be above average in the computer use and intelligence department. Those are scary odds. 1 in 75. Until a year ago we had no infections.
At any rate, I think JRiver has heard it enough and can make up their own mind what they think is reasonable. They have the facts, lets see what they decide to to.
-
The internet is the same way, if you are stupid enough to browse porn, piracy, or any other questionable site on an embedded browser you deserve what you get just for acting a fool.
Interestingly, in a recent study by Avast (http://www.theregister.co.uk/2010/06/30/unsafe_surfing/), they found that "regular sites" beat porn sites (and other illegitimate sites) in hosting malware. I've personally seen very aggressive malware being served by websites like: MSNBC, AppleInsider, LifeHacker, and AnandTech. I've read reports about similar occurrences at places like the New York Times, CNN, and the BBC, among many others. Some of the WORST offenders are Web Forums (running on systems like Interact), personal blogs run by inexperienced website operators, and hardware OEM websites for old and discontinued products. Most of these get infected simply through neglect, and the virus and malware makers creep in through holes in old versions of the software running on the sites.
Interestingly, in that study and many others, they found that "porn sites" in particular (especially mainstream ones that are actually selling access to the site rather than just scraping other available content), were actually substantially safer than many other "classes" of sites. Which makes sense if you think about it... If your business is to sell access to your website for a monthly fee and keep the users coming back and paying that monthly $19.99 bill, it doesn't serve you very well to infect their machines with all sorts of nefarious malware which will only serve to make the user experience of accessing your site a poor one.
For the big-name sites, these infections almost always come from the ads. The problem is that many of the ad networks don't monitor or filter their content very well, and the distribution systems they use are almost always easily compromised. So, if you are a malware maker looking to infect as many machines as is possible in one fell swoop (in order to build your zombie machine botnet of destruction), it is a nice juicy target to attack these ad networks. You get instant wide distribution, and even better your content is distributed on "legitimate sites" that many people trust, meaning that if the users get an ActiveX permission dialog (or whatever), many people will mindlessly approve it thinking that the BBC or MSNBC couldn't possibly be attacking their machine (not reading the dialog itself to look at the publisher's signature).
Crafty email phishing scams are also a common source of problems, of course. Many users just aren't very sophisticated. I guess all I'm pointing out is this... I think there can sometimes be in the hardcore tech community a strong "blame the dumb user" undercurrent to security discussions. In other words, you didn't update your browser/Flash/Java/Windows/etc and you got infected, so it is "your" fault. The car analogy is a perfect example, you don't blame Toyota if you don't know how to drive and you crash the car (well, actually that does happen, I guess).
However, the analogy breaks down completely when you look at the utter complexity of trying to update a modern Windows PC for the "average" user. These people don't even fully understand what a "browser" is, and how it is different from "Flash" or "Java" or the operating system. My mom doesn't fully grok the difference between "Windows" and "Office" (she calls them both "Microsoft"). How can we, as an industry, expect that user to be able to fully maintain a working and secure system when it is designed for a tinkerer and expert? It is absurd! Windows has dramatically improved with the modern versions of Windows Update which actually seem to work right most of the time, but even this system breaks down: Just the other day, I discovered that one of my Win7 machines hadn't gotten any updates in MONTHS because there was some "Critical patch" to the Windows Update system itself that didn't auto-update itself like it is supposed to (for whatever reason) and which needed to be installed or all future updates were being held back. The only reason I found it was that I happened to go into the Windows Update tool and checked for updates manually because I was looking for updated drivers for a crappy Microsoft Webcam (and I was too lazy to Google search and figured I'd just use Windows Update).
On my mom's machine, this would have sat unnoticed essentially forever. If she didn't know me, she'd be in deep trouble. And then we have to update Flash, and Java, and Acrobat, and our Anti-Virus, and our browsers, and so on and so forth. Your router might need firmware updates, and now even your phone runs complex software (Flash on phones still seems like a Really Bad Idea). Plus, they have to be able to monitor the system to make sure it is being backed up properly (with systems typically designed with a computer expert in mind). Many of these systems remind you, but often they do it at inappropriate times when you're just trying to "get work done" (the worst are ones that only notify you at login). And then they're often designed that if you click "OK" or "Not Now" the dialog goes away and never returns and you're expected to just remember which application needed the critical update. It is absurd. The DESIGN of modern computer system security is so decentralized and complex that it is effectively DESIGNED for it to fail for the average person.
Taking that same analogy, imagine if there were critical recalls on your Toyota almost every single week, that are suddenly absolutely essential to the safe operation of your vehicle. And then imagine that these recalls were announced to you in a wide variety of different ways: some via email, some via phone, some via mail, some by the car itself, and some not at all (you're just expected to "know" to check). And then, imagine that you can't just bring the car into the dealer to get a repair, but you have to deal with each individual component manufacturer individually, and usually install the fix yourself, with limited instructions which assume that you are a fully certified car technician. And then imagine that all the while your car seems to be actively trying to trick you, flooding you with lying emails about fake updates and invalid security prompts and warnings that don't really apply to you. This is the environment that most people find themselves in at home with their PCs. It is an absurd situation, and it should surprise absolutely no one that it fails spectacularly with regularity.
So... Uneducated users are certainly a problem. But bigger problem is that we design systems that require the users to be security experts and technicians in order to use them safely, and then we effectively require "regular people" to use these systems for their everyday life. You honestly can't get a good job at all if you don't have some basic level of computer skills and Internet access in the West. And that's just going to get "worse". And then we do an amazingly poor job of educating our children about these systems. Using a computer is probably the single most important life skill you can have before you enter the modern workforce in America. But our schools treat computer skills as an almost extracurricular afterthought (just like we do with finances, we teach them math and basic history, but NOTHING about money at all in our schools). Our schools are designed to teach the skills that the baby boomers needed to succeed in the world, not for the modern work world at all.
-
Wow very well said. I've read a lot on those issues and that is about the clearest I've seen it explained in terms that most users can understand.
Also I think porn sites (pay ones) spend a considerable amount of money keeping unpaying customers out, and monitor their systems constantly. So it isn't really surprising that they are not full of malware. However I think at the same time many "free porn" sites are created to lure unsuspecting customers into visiting so they can be infected. It also has the added bonus of embarrassment so many users won't tell others to be wary of the site etc. I think however that criminals have moved over to more lucrative territory via Ad's just like we mentioned...
Also interesting I think porn has been a driving force behind much that has happending on the internet. They were among the first pay sites, so they had to create monitoring and security. They had to create ways to accept money over the Internet. And they needed streaming video etc. They were doing these things long before they were mainstream.
-
So what has all this got to do with the topic? JRiver can't do anything to change the inherent risks. They can't be sued for not using IE. As glynor points out, failures in countermeasures can occur no matter what methods are used. Whatever JRiver does—for the sake of minimizing their corporate risk and serving their customers—needs to be reasonable in the circumstances. They may not need our help, but if there's anything to be discussed, shouldn't it be that? What's a reasonable way of ensuring the embedded browser is reasonably up-to-date wrt security measures? What reasonable measures can be taken to ensure all users' installations of MC are sufficiently up-to-date for the safe use of the embedded browser? In making these determinations, is it reasonable to assume all users have some minimum standard of effective firewall and virus protection installed?
-
So what has all this got to do with the topic?
Very little, if anything. We're just having a conversation. Interact has always been relatively tolerant of "drifting topics" in threads, especially longer ones. Eventually it usually comes back around to some sort of point, peters out, or gets split off if Jim is in a particular mood that day. ;) ;D
-
I don't mind the drifting—it's all very interesting. I just thought the topic might be an interesting tangent. ::) ;D
-
Thanks for the thoughtful, well written and intelligent post (#85), glynor. I think it's relevant to the topic because once you're open to the web, it's possible to get viruses, etc. And as I learned above, it's easier to run into trouble than I previously thought. I'm fairly careful, but I've noticed that Bing searches off the MSN home page can lead to sites that I'd rather not visit. It's very true that maintaining a personal computer that runs well and avoids problems is much more difficult than it should be.
-
I really really doubt the problems with IE9 are the fault of J River not doing things right. I also don't understand why Microsoft released IE9 as an RC when it obviously causes problems with programs that have IE embedded as an internal browser component. Normally an RC should be much more stable than that, especially an RC that is released as publicly as IE9. RC means different things for different companies, and even within Microsoft I'm not sure if RC means the same thing to all groups. But wow Microsoft. You don't release an RC in a state like that. If I was doing QA for IE9 and released an RC like that I'd be embarrassed (and probably fired). You just don't do that if QA is doing their job. And anyone doing QA for a project like IE9 should be highly competent and skilled, so frankly there is no excuse.
I am a bit curious if any of the MSDN samples for embedding IE also crash with IE9? I'm not curious enough to make a testing environment, install IE9, and test them out. That's too much like work. But if any of the MSDN samples do crash there is no excuse for the QA to have missed it. It's just too easy to add MSDN samples to a test suite and too easy to test if they crash.
If MS did need to intentionally break backwards compatibility like that for some legitimate reason they would have known that the RC would cause problems and should have publicly explained the what's and why's long before the RC release.
I don't blame J River for switching to Chromium. I'd be a bit angry (privately I'd use stronger language than just a bit angry) at MS for that. Having your app crash is bad for business, even if it's not your fault.