Hi, Upstream have said: https://code.google.com/p/chromium/issues/detail?id=491435#c10 > This is not "opt-in default". If you do not explicitly opt in (using > the "Enable Ok Google" setting in chrome://settings), then this module > will not run.
That suggests to me that security of users was not put at risk, unless they enabled that optional feature. It was likely 'only' a privacy concern and Debian policy violation. May I ask boldly, is NaCl a legitimate feature of a Debian package in 'main'? I'm reminded of the FSF's John Sullivan speaking at DebConf14 about the DFSG iceweasel browser offering to install non-free software. AIUI NaCl's only purpose is to execute compiled, most likely non-free code? (Whereas minified non-free JavaScript is objectionable to some, this seems an order of magnitude worse). I'm not implying chromium belongs in contrib or non-free - there is already the non-free Chrome as an option there - but rather, would the DFSG chromium browser be 'more' free if it disabled NaCl? I also propose more QA within Debian to find applications phoning home, which could have been detected in this case within something like the autopkgtest framework and simply opening a page on a local webserver. Sorry, if you feel this is off-topic for the bug log, please take it to an appropriate list but preferably keep me in Cc: if you do. Christoph Anton Mitterer wrote: > And there's still no single sign of properly visible announcements to > user what might have happened here. :( The bug made it to Hacker News, so that has been accomplished now to some extent. Thanks Chris for speaking up about this. Regards, -- Steven Chamberlain ste...@pyro.eu.org
signature.asc
Description: Digital signature
