See for example http://www.zdnet.com/article/a-close-look-at-how-oracle-installs-deceptive-software-with-java-updates/
S. On Thu, Oct 29, 2015 at 6:57 PM, Greg Bullock <g...@nwra.com> wrote: > Would you confirm that, about the adware/spyware tricks? If confirmed, > that would definitely interest me. > > Perhaps it's just my obliviousness or rapidly fading memory, but I don't > recall ever seeing a trap on Oracle's Java download trying to install > adware/spyware. > > > http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html > > I've used Java (JRE, JDK and Netbeans) on Windows actively for 5+ years, > and occasionally for longer than that, and I just don't recall seeing a > malware trick there. I see them on other sites for other software, but not > there for Java. > > Greg > > > > > On 10/29/2015 11:44 AM, Simon Phipps wrote: > >> One more factor to consider is that the official Java installer promoted >> by >> Oracle tries really hard to trick the end-user into installing >> adware/spyware at the same time. We used to avoid this in the Sun >> installer >> by bundling Java, but having it as an external dependency for new AOO >> users >> means they face the challenge not only of finding and installing Java but >> avoiding the malware as they do so. >> >> I'd say this was a really big negative for a dependency on official Java. >> It's not a problem on Linux where there is usually an OpenJDK bundle >> available, but it's a huge negative on Windows. >> >> S. >> >> >> On Thu, Oct 29, 2015 at 5:44 PM, Dennis E. Hamilton <orc...@apache.org> >> wrote: >> >> The Java dependency problem keeps coming up buried in other threads. I am >>> redirecting the most recent case so we can put light on this situation. >>> >>> Before the dependencies on Java are increased/improved, I think there is >>> a >>> crucial usability matter. >>> >>> 1. Currently users are trap-doored by exercising a feature or dialog >>> that >>> suddenly raises a Java dependency, sometimes for which there is no escape >>> other than finding a way to shut down AOO that is not a normally-required >>> skill. >>> >>> 2. The fact that full functioning of AOO is buried in the system >>> requirements in a way that users can easily overlook (or never examine) >>> is >>> a problem. We can fix that page, even providing (or linking to) specific >>> details of what the dependencies are. That would be useful so developers >>> and power-users have the details. However, the system requirements are >>> probably not read by most who download the software (based on over 40 >>> million downloads of 4.1.1, overwhelmingly on systems designed for casual >>> users). >>> >>> 3. If the installer required presence of Java, that would be a clear >>> indication that it is required for operation. It would also be helpful >>> if >>> the installer provided an usable link for installing a workable Java if >>> one >>> is not present. >>> >>> 4. If the presence of Java is indeed optional, and the user does not >>> have >>> it or elects not to use it, AOO should not even offer functions for which >>> Java is required. That is another way to improve the usability and at >>> least avoid users falling through trap-doors. >>> >>> 5. Shouldn't we do this better? Or are we to decree that AOO is only >>> intended for power-users who have strong skills with regard to managing >>> their configurations, managing the install of dependencies, >>> trouble-shooting and being able to work around the not-dependable way >>> things work now? >>> >>> Three paths come to mind. >>> >>> A. Remove the Java dependencies. >>> >>> B. Adjust the Java dependencies, >>> 1. So that the dependencies are clear and the situation around >>> failures to find a suitable JRE is made workable for casual users. This >>> could involve the above (2-4) remedies. >>> 2. Only then consider increasing the dependencies on Java for >>> full-function operation in some controllable way. >>> >>> C. Make AOO a Java application that has C++ components, rather than the >>> reverse. >>> >>> These are all serious. Probably on the way to either A or C, one must >>> address B. >>> >>> We also need to consider what the project's capacity for any of these >>> cases happens to be. >>> >>> Thoughts? >>> >>> - Dennis >>> >>> PS: There is a bigger question about platform presence in here. There >>> are >>> distributions for which Java dependency is not particularly attractive >>> and >>> we may be cutting ourselves off from those. That might not matter if we >>> are talking about the small percentage of the downloads that are for >>> neither Windows nor Macintosh desktop PCs. >>> >>> >>> >>> -----Original Message----- >>>> From: Pedro Giffuni [mailto:p...@apache.org] >>>> Sent: Thursday, October 29, 2015 08:07 >>>> To: Apache OO <dev@openoffice.apache.org> >>>> Subject: Re: Thinking of joining OpenOffice as a developer >>>> >>>> Hello; >>>> >>>> First of all, a warm welcome to Patricia. Java developers are >>>> particularly welcome at this stage! >>>> >>>> Just IMHO, the C++ side of AOO is either under-control or >>>> too-ugly-to care-about, so we would do good focus more on the >>>> Java parts, which are also somewhat ugly but still promising. >>>> >>> [ ... ] >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>> >>> >>> >> > -- > Greg Bullock > NorthWest Research Associates > 301 Webster St. > Monterey, CA 93940 > (831) 582-4907 > g...@nwra.com > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > > -- *Simon Phipps* http://webmink.com *Office:* +1 (415) 683-7660 *or* +44 (238) 098 7027 *Mobile*: +44 774 776 2816 *or Telegram <https://telegram.me/webmink>*
