三悼谷歌

上一篇文章:https://blog.axqd.net/2010/03/23/mourn-again/

Google an update on china

Ever since we launched Google.cn, our search engine for mainland Chinese users, we have done our best to increase access to information while abiding by Chinese law. This has not always been an easy balance to strike, especially since our January announcement that we were no longer willing to censor results on Google.cn.

We currently automatically redirect everyone using Google.cn to Google.com.hk, our Hong Kong search engine. This redirect, which offers unfiltered search in simplified Chinese, has been working well for our users and for Google. However, it’s clear from conversations we have had with Chinese government officials that they find the redirect unacceptable—and that if we continue redirecting users our Internet Content Provider license will not be renewed (it’s up for renewal on June 30). Without an ICP license, we can’t operate a commercial website like Google.cn—so Google would effectively go dark in China.

That’s a prospect dreaded by many of our Chinese users, who have been vocal about their desire to keep Google.cn alive. We have therefore been looking at possible alternatives, and instead of automatically redirecting all our users, we have started taking a small percentage of them to a landing page on Google.cn that links to Google.com.hk—where users can conduct web search or continue to use Google.cn services like music and text translate, which we can provide locally without filtering. This approach ensures we stay true to our commitment not to censor our results on Google.cn and gives users access to all of our services from one page.

Over the next few days we’ll end the redirect entirely, taking all our Chinese users to our new landing page—and today we re-submitted our ICP license renewal application based on this approach.

As a company we aspire to make information available to users everywhere, including China. It’s why we have worked so hard to keep Google.cn alive, as well as to continue our research and development work in China. This new approach is consistent with our commitment not to self censor and, we believe, with local law. We are therefore hopeful that our license will be renewed on this basis so we can continue to offer our Chinese users services via Google.cn.

Posted by David Drummond, SVP, Corporate Development and Chief Legal Officer

关于谷歌中国的最新声明

2010 年 6 月 28 日

David Drummond, SVP, Corporate Development and Chief Legal Officer

自从为中国大陆用户推出 Google.cn 这个 搜索引擎以来,我们一直在尽最大的努力来提高用户对信息的访问,同时遵守中国法律。做到这样的平衡并不容易,尤其是我们在今年1月份宣布不愿意继续在 Google.cn 上对搜索结果进行审查。

当前,我们把所有访问 Google.cn 的用户自动指向了我们香港的搜索引擎 Google.com.hk,通过这种方法,我们可以提供未经审查的简体中文 搜索结果。目前这种方法无论对用户还是对 Google 都运行良好。然而,在与中国有关部门的沟通中我们明确获知:自动指向的做法是不可接受的。如果我们继 续进行自动指向,我们的 ICP 牌照将无法通过年检(年检截止时间是6月30日)。没有 ICP 牌照,我们将不能在中国运营 Google.cn 这样的商业网站——这意味着 Google.cn 将不能被访问。

那是许多 Google 中国用户所担忧的结果,因为他们都清楚表明了希望 Google.cn 继续运营的愿望。为此,我们开始寻找其他可能的替代办法,我们开始为一小部分用户提供一个新的 google.cn 访问页面,该页面与 Google.com.hk 链接,在那里,用户可以进行搜索,或继续使用在 google.cn 上的音乐搜索(Music Search)和文本翻译(Translate)等不涉及内容审查的服务。这个新做法确保 Google.cn 不对搜索结果进行审查的承诺,同时让用户可以在一个页面上访问我们所有的服务。

未来几天,我们将全部停止自动指向,让所有中国用户都直接访问这个新页面——今天,基于这样一个新页面,我们重新提交了 ICP 牌照年检申请。

作为一家公司,我们的追求是让用户随时随地访问到他们所需的信息,包括中国的用户。这就是为什么我们一直在努力地保持 Google.cn 的运营,以及继续我们在中国的研发工作。这个新做法确保了 Google.cn 不对搜索结果进行审查的承诺,并且,我们相信,符合中国法律。因此我们希望能够通过 ICP 牌照年检,让我们可以继续通过 Google.cn 为中国用户提供服务。

McAfee’s Crisis PR

只简单说几句:

  1. 一定要快,隔离影响,提供解决办法;
  2. 不要在说对不起之前,做大量的解释,这人很愚蠢;
    http://siblog.mcafee.com/support/mcafee-response-on-current-false-positive-issue/
    http://siblog.mcafee.com/support/a-long-day-at-mcafee/
  3. 技术上没任何理由,在赛门“误杀门”之后,白名单还能漏掉系统重要文件;
  4. QA Test Matrix漏掉Windows XP SP3是足以让所有用户震怒的事情;

转载自:http://blogs.zdnet.com/Bott/?p=2031

McAfee admits “inadequate” quality control caused PC meltdown

Update 23-Apr: Late Thursday night, McAfee posted a FAQ on this issue at their web site. The FAQ includes some of the text from the confidential document I received yesterday and is clearly a later version of that document. However, the details of why the problem occurred and the specific steps that the company plans to take to avoid similar problems in the future have been replaced with general statements. I have highlighted the differences in updates below.

As of 6AM Pacific time on 23-Apr, there is still no statement, apology, or clearly labeled link to support resources related to this issue on McAfee’s home page.

If your company uses enterprise security products from McAfee, you probably had a bad day yesterday. If you’re an IT professional at one of those companies, you’re probably still cleaning up the mess caused by a defective virus signature update that disabled systems running Windows XP with the most recent service pack (SP3). The worst part? According to a confidential document from McAfee, the cause was a fundamental breakdown in the most basic of quality-assurance processes.

From an IT perspective, this is a nightmare scenario: an automatic update that wipes out a crucial system file and that can only be repaired manually. I’ve heard from more than a dozen IT pros and consultants over the past 24 hours who shared their experiences. They are, to put it mildly, unhappy.

What went wrong?

That was the question I asked in my post yesterday, and I formally asked a McAfee spokesperson for an explanation this morning. I was told that an answer will be posted on McAfee’s blog later today. As of this writing, that blog post has not been published.

But I found the answer, straight from the source, in a document forwarded to me by an anonymous source. According to my source, the document was “a confidential communication to enterprise customers” sent via e-mail. In it, the anonymous author acknowledges that the screw-up was thoroughly preventable. The document, titled “McAfee FAQ on bad DAT issue,” is written in Q&A format and includes the following exchange:

8. How did this DAT file get through McAfee’s Quality Assurance process?

There are two primary causes for why this DAT file got through our quality processes:

1) Process – Some specific steps of the existing Quality Assurance processes were not followed: Standard Peer Review of the driver was not done, and the Risk Assessment of the driver in question was inadequate. Had it been adequate it would have triggered additional Quality Assurance steps.

2) Product Testing – there was inadequate coverage of Product and Operating System combinations in the test systems used. Specifically, XP SP3 with VSE 8.7 was not included in the test configuration at the time of release.

Update 23-Apr: The details I quoted above have been scrubbed from the FAQ posted at McAfee’s website. The corresponding section of the FAQ now reads as follows: “The DAT release was designed to target the W32/Wecorl.a threat that attacks system executables and memory. The problem arose during the testing process for this solution. We had recently made a change to our QA environment. Unfortunately, this change resulted in a faulty DAT making its way out of our test environment.”

McAfee has also sanitized the portion of the FAQ that describes its plans to adapt its quality control procedures. Here’s the original text of the confidential document sent to enterprise customers:

9. What is McAfee going to do to ensure this does not repeat?

McAfee is currently conducting an exhaustive audit of internal processes associated with DAT creation and Quality Assurance. In the immediate term McAfee will do the following to provide mitigation from false detections:

1) Strict enforcement of rules and processes regarding DAT creation and Quality Assurance.
2) Addition of the missing Operating Systems and Product configurations.
3) Leveraging of cloud based technologies for false remediation.
4) A revision of Risk Assessment criteria is underway.

And here is the corresponding text as it appears in the final FAQ, published overnight:

What is McAfee going to do to prevent this from happening again?

Nearly all of our 7,000 employees have been working around the clock to help customers like you get back to business as usual and to make sure this never happens again. The vast majority of our customers are now back up and running and we remain focused on those that remain affected.

We are implementing additional QA protocols for any releases that directly impact critical system files. We are also rolling out additional capabilities in Artemis that will provide another level of protection against false positives by leveraging an expansive whitelist of critical system files and their associated cryptographic hashes.

That is mind-boggling. For enterprise customers, Windows XP SP3 is probably the most widely used desktop PC configuration. Leaving it out of a test matrix is about as close as one can get to IT malpractice. Any enterprise customer who received this document has every right to be furious.

Meanwhile, McAfee’s website is almost completely silent on the issue. Customers who have been affected by the issue who visit the McAfee U.S. home page see business as usual, with a rotation of large ads trumpeting McAfee’s latest products. More than 24 hours after the problem occurred, only a single front-page link is available, and it’s blandly headlined, “McAfee Response on Current False Positive Issue.” If you go to McAfee’s Enterprise home page, there is no mention of the problem and no link to any support resources. An overseas correspondent sent me a screen shot of McAfee’s UK home page, which also has no mention of the issue.

That link leads to a blog post by McAfee’s Barry McPherson, published yesterday at 4:29PM. McPherson seems more intent on praising McAfee’s researchers and minimizing the problem than helping users. He writes: “We believe that this incident has impacted less than one half of one percent of our enterprise accounts globally…” I find it difficult to believe that the company could come up with an accurate estimate at all, much less do so within hours after the problem was identified. It certainly doesn’t match up with the reports I’m hearing from the field.

Update 23-Apr: Yesterday afternoon, the McAfee blog post was edited to remove this reference. The sentence now reads, ” We believe that this incident has impacted a small percentage of our enterprise accounts globally and a fraction of our consumer base…”

From a crisis management perspective, McAfee’s response has been disastrous. If the company truly cared about its customers, the home page would contain an apology from the CEO and links to detailed support information. Instead, it appears that the company is hoping its customers will just forget about it.

Based on the 100+ comments to McPherson’s post, customers who were hit by this error aren’t likely to forget about it soon. And when they figure out that a lapse in the most basic of quality control steps caused them to spend thousands of dollars in IT manpower and lost productivity, they’re likely to be angrier still.

转载自:https://kc.mcafee.com/corporate/index?page=content&id=KB68787

McAfee DAT 5958 False Positive Error – FAQ

Summary
Please note that investigation of this issue is ongoing, and these FAQs will be updated appropriately as we learn more.

What threat was McAfee trying to detect that resulted in a false positive error?
McAfee added detection for variants of the W32/Wecorl.a threat in DAT file 5958. This detection caused a false positive on the svchost.exe Windows system file. The threat parasitically patches the svchost.exe file by modifying data at the entry point or the entry point itself of the original file, to maintain control on the system. In some instances the patch has been found to be polymorphic in nature. McAfee had observed prior infected versions of svchost.exe files and had detection for this threat. This specific detection was added to target a cluster of infected svchost.exe files gathered through our malware collections, directly associated with samples from the W32/Wecorl.a families.

The false positive occurred as a result of new signatures targeting new variants of the Wecorl family of malware when invoked on the file svchost.exe as a part of the memory scanning process. Details of this threat family can be found here: http://vil.nai.com/vil/content/v_153184.htm. Enhanced drivers in the 5958 DAT were authored to detect some low prevalence variants seen recently.

Why did detection for this threat require an invasive approach for detection and remediation?
To remediate this type of threat, detection is customarily written to kill the infected process, in some instances causing a reboot (a standard Microsoft safety action), and allowing for full remediation of the infected system. This type of remediation is standard implementation to gain access to the file objects that may be locked by the running processes.

Unfortunately this caused removal or attempted removal of legitimate svchost.exe file causing issues from network connectivity loss to rendering systems unstable due to the false positive.

Doesn’t McAfee white list known Windows system files?
Complex and sophisticated malware frequently target Windows system executables and attack their memory space (e.g. via DLL injection). McAfee DATs use Whitelisting techniques to avoid scanning and preventing false positives on Microsoft files in the majority of situations, for example, if this was a simple scan of the file as it was accessed on the file system, a false positive would have been prevented. But because this was a memory scan of the running process that then caused a subsequent scan of the file on disk these mitigation techniques were unfortunately not invoked.

Exactly which versions of Windows operating system and the svchost.exe file were affected?
A subset of systems running Windows XP Service Pack 3 and having specific versions of the svchost.exe file were affected. Svchost.exe files found on Windows 2000, Windows 2003, Windows XP Service Pack 1, Windows XP Service Pack 2, Windows Vista, Windows 7 and older versions of Windows were not affected.

Details of svchost.exe files affected are:

File Size OS File Version Md5
14,336 XPPRO_SP3_x86_v1 5.1.2600.5512 E4 10 EC 73 E2 BE 2A 41 D9 23 B0 06 F5 1C 84 27
14,336 XPPRO_SP3_x86_v2 5.1.2600.5512 27 C6 D0 3B CD B8 CF EB 96 B7 16 F3 D8 BE 3E 18
14,336 XPPRO_SP3_x86_v3 5.1.2600.5512 A7 81 24 26 8A 77 F4 19 02 DB 18 F6 22 AF E6 13

How exactly were user systems impacted?
McAfee corporate customers who have the McAfee VirusScan Enterprise product have reported a variety of symptoms, ranging from a system “blue screen” (not to be confused with BSOD, but due to the issues with Explorer and svchost.exe), loss of network connectivity, inability to use USB, and experiencing a perpetual state of reboot. Users have reported these symptoms when both the file is present on the system (in quarantine), or has been deleted entirely.

Minimal impact has been observed to McAfee’s consumer customers because McAfee rolled back the faulty DAT before the update hit the majority of consumer user systems.

Why was VirusScan Enterprise 8.7 primarily affected as compared to VirusScan Enterprise 8.5?
Because of the different implementation of memory scanning within the products, VirusScan Enterprise 8.7 customers were more broadly affected by the false positive.

How do affected customers restore their systems?
McAfee has enumerated instructions to restore systems to their normal functional state with the right critical Windows files in place. McAfee has also developed a SuperDAT remediation tool to restore the svchost.exe file on affected systems.

Specific instructions are available in the McAfee KnowledgeBase in KB68780.

How did this DAT file get through McAfee’s Quality Assurance process?
The DAT release was designed to target the W32/Wecorl.a threat that attacks system executables and memory. The problem arose during the testing process for this solution. We had recently made a change to our QA environment. Unfortunately, this change resulted in a faulty DAT making its way out of our test environment.

What is McAfee going to do to prevent this from happening again?
Nearly all of our 7,000 employees have been working around the clock to help customers like you get back to business as usual and to make sure this never happens again. The vast majority of our customers are now back up and running and we remain focused on those that remain affected.

We are implementing additional QA protocols for any releases that directly impact critical system files. We are also rolling out additional capabilities in Artemis that will provide another level of protection against false positives by leveraging an expansive whitelist of critical system files and their associated cryptographic hashes.

McAfee recommends customers sign up for our Support Notification Service to get real critical product information via e-mail. Go to the SNS Subscription Preference Center to subscribe. For more information, view the SNS KnowledgeBase article and FAQ: KB67828.

Ashes to ashes, Dust to dust

KV300是我购买的第一个正版软件。此前,我先是用几块钱,买了盗版的KV100。然后KV搞活动,加了点钱,在联邦软件专卖店,用盗版换购了正版的KV300(介质还是3.5寸的软盘)。此后,每周去联邦软件专卖店升级KV300的病毒定义库,成了必不可少的功课。拿回家杀毒,若能查出几个病毒来,那种喜悦现在已然难以体会。当然,也因为经常升级的缘故,软盘经常损坏,换一次就60大洋。

不管怎么说,王江民,自然而然,也成为了我儿时的偶像。如今59岁英年早逝,天地齐咽。愿你在天堂迎得一片真正的“净土”,彻底实现你“杀毒”的宿愿。

王江民
王江民

Shutter Island

Big Fish》带给我的感动,仿佛已经是上个世纪的事情了。之后看了很多电影,都只能说还行。今天终于又被感动了一把—《Shutter Island》。非常佛洛伊德的一部片子。

至于对这部电影可能两个版本的理解:如果他是Teddy,说出”Live as a monster, or die as a good man”之后,选择Lobotomy,实在就显得有些消极了,作为Marshal当然还是应该想尽办法逃离,以帮助众人逃离;反之,如果他是Andrew,最后已然清醒,为了忘记发生在自己身上的悲痛,为了让自己不再伤害他人,而勇敢的继续假扮Teddy选择Lobotomy,多少还有些英雄气魄…

一部电影,看完还能让人有完全相反的两个版本的解读,不得不赞一个…

潲水油

十多年前,我吃过“芙蓉豆腐庄”,那味道真叫一个赞。后来被查出来潲水油,作呕不止。当时甚至有人开着奔驰停在店外,找卖水果的老农买了一根扁担,将它一通乱砸。

十多年后的今天,潲水油又被查了出来,只是换成了13家火锅。

“潲水油”作坊被查处 13家进货火锅店挨处罚
转载自天府早报:

早报讯(记者 吴楚瞳)昨日,成都市食安办发出了关于政府相关部门采取坚决措施,查处违法加工销售和使用劣质食用油行为,大力整顿食用油市场的情况通报。经联合调查组确认,谷丰香油坊非法经营、加工、销售“大丰香油”构成“无证无照生产经营”、“以假充真”和“伪造、冒用他人厂名”和“伪造、冒用他人生产许可证”的违法行为。成都市质监局、工商局依据《产品质量法》第五十条相关规定,给予谷丰香油坊行政处罚;成都卫生部门将依据《食品安全法》对13家火锅店违规购买、使用“大丰香油”的行为,依法进行行政处罚。

近日,成都市食安办组织相关职能部门对所有取得食品生产许可证的食用植物油生产加工企业、食用油加工小作坊,粮油经营(批发)店,农贸市场、粮油批发市场,餐饮服务企业,单位(工地)集体食堂展开为期1个月的食用油专项整治。成都市质监局、市工商局、市卫生局等部门响应,截至目前,已完成了全市3000多户中餐店、878 户火锅店食用油来源和五块石粮油批发市场及40家芝麻油生产企业进货、销售情况的检查。

为建立健全食品安全长效工作机制,成都市食品安全委员会日前召开了成员单位会议,从四个方面强化工作措施。指出将通过典型案例进行警示宣传。

言之凿凿,却TMD连一个火锅店的名字都没有。

好在有网民爆料,才有了下面这个未经证实的名单:

  • 味道江湖
  • 百姓人家
  • 三只耳
  • 蓉城老妈
  • 奇火锅
  • 小天鹅
  • 皇城老妈
  • 蜀九香
  • 胖妈烂火锅
  • 秦妈火锅
  • 川王府火锅
  • 刘一手
  • 孔亮

我嘴贱,全都TMD吃过…

Updated:

成都公布13违规火锅店 澄清其所用并非潲水油
转载自:http://cd.qq.com/a/20100330/001659.htm

导读:“犹抱琵琶半遮面”的13家违规火锅店名单终于经由官方公布了,同时市卫生局澄清,之前提及的“潲水油”火锅是误传,违规油实际是玉米油加香精勾兑的…

成都市食安办通报“大丰香油”事件称,是香精兑玉米油冒充“芝麻香油”

昨晚8点30分,成都市食品安全委员会办公室(下简称:市食安办)举行新闻发布会,邀请工商、公安、卫生、质监等行政监管部门,就谷丰香油坊非法加工销售“大丰香油”事件的最新情况向社会通报。
经查,该香油坊非法加工的芝麻香油是用食用玉米油和食用香精勾兑而成,属于非法加工、“以假充真”的芝麻香油。证据表明,可以排除该香油坊生产销售“潲水油”的嫌疑。
目前,谷丰香油坊的3名涉案人员已被刑拘。现场还公布了违规使用“大丰香油”的13家火锅店名单。

案件进展3涉案人员已被刑拘

成都市食安办主任周蓉说,近段时间以来,市民对谷丰香油坊非法加工销售“大丰香油”事件给予了高度关注。3月10日,金牛区工商局和质监局就已介入调查。17日,成都市公安局对3名涉案人员实施了刑事拘留。26日,成都市公安局、质监局、工商局、卫生局经过调查取证,对违法事实进行了认证。
经查,3名涉案人员为亲属和亲戚关系。刘磊,男,25岁,河南夏邑人,谷丰香油坊业主。大学毕业后随父亲刘志峰从事香油加工、销售,曾因妨害公务罪被金牛区法院判处拘役5个月。刘志峰,男,45岁,刘磊之父。在成都从事香油加工、销售。刘月光,男,24岁,河南商丘人,刘磊表弟。高中毕业后到成都投靠刘磊、刘志峰,从事香油加工、销售。

违法事实香精+玉米油充麻油

2009年3月,刘磊在金牛区工商局办理了《个体工商户营业执照》,经营范围为销售预包装食用植物油,未取得加工食用油的资质。
谷丰香油坊的违法事实是,分别从成都郫县原野实业有限公司购进食用玉米油,从山东省滕州市润隆香料有限公司购进食用香精,以食用香精代替芝麻油,经过数次勾兑和掺合,非法加工成以假乱真的“芝麻香油”。
谷丰香油坊冒用“成都原野实业有限公司”的企业名称和食品生产许可证号,伪造与加工地点不相符合的厂址以“大丰香油”名称进行销售。
周蓉通报说,谷丰香油坊上述非法加工、销售“大丰香油”的行为构成了“无证无照生产经营”、“以假充真”、“伪造、冒用他人厂名”和“伪造、冒用他人生产许可证”的违法行为。成都市质监局、市工商局依法给予谷丰香油坊行政处罚。

证据表明可排除“潲水油”嫌疑

经公安、质监、工商部门现场搜查、勘验和对扣押的工具、原料等物品的仔细检查,均未发现与熬制“潲水油”有关的物品,走访现场附近群众也未有谷丰香油坊生产“潲水油”的反映。
经审查涉案人员的加工制作程序,证据表明,可以排除谷丰香油坊生产销售“潲水油”的嫌疑,其不法行为定性为非法加工、销售食用油。
据悉,成都市工商、质监、卫生部门对有关监管人员失职、失察行为,予以行政处罚。

澄清误传13家火锅店名单公布

经查实,购买使用“大丰香油”的火锅店共计13家。成都市卫生部门依据《食品安全法》对违规购买、使用“大丰香油”的13家火锅店,依法行政处罚。昨晚成都公布了违规使用“大丰香油”的13家火锅店名单,对社会上的误传予以澄清。
针对之前媒体报道说,“成都市食安办的负责人说是‘潲水油’”的说法,周蓉也进行了澄清,她称,记者所指的市食安办负责人有误,他是成都市食品药品监督管理局的人员。

13家违规使用“大丰香油”火锅店名单

  • 老码头餐饮娱乐有限公司;
  • 邓毛肚火锅店;
  • 高新区忆香缘火锅店;
  • 川江号子餐饮发展有限公司玉林、长顺店;
  • 香天下餐饮有限公司;
  • 蓉鼎香餐饮有限公司;
  • 老庄火锅店;
  • 辣元素餐饮管理公司;
  • 成都张老山火锅店;
  • 巴蜀大宅门火锅店;
  • 蜀九香SM店;
  • 新蜀九香餐饮有限公司紫荆店;
  • 成都市圆满香餐饮管理有限公司

答记者问

“成都火锅店是让人放心的”
什么是“潲水油”,什么是“地沟油”,为何“大丰香油”不是潲水油?
发布会上,成都市食安办主任周蓉、成都市工商局公平交易执法局局长黄生、成都市公安局经济犯罪侦查处政委郑跃伟、成都市卫生局卫生执法监督支队副支队长李宏坤、成都市质监院食品检测中心主任万渝平回答了记者提问。

为何不是“潲水油”?
记者:为什么说“大丰香油”不是“地沟油”、“潲水油”?
万渝平:俗称的“潲水油”是从餐饮行业的废弃食物残渣中提取的油。地沟油是地下水道漂浮的油腻物品中提取的物质。非法加工的食用油,是违反食品安全法,违反产品质量法,违反标准化法生产的食用油。
从检测结果来看,查处的“大丰香油”以食用玉米油为主要原料,以食用香料勾兑调配而成。依据国家标准2716食用植物油的卫生标准进行检测,该油的指标符合卫生标准的规定。
郑跃伟:调查中,没有发现该香油坊存在生产潲水油工具和原料。我再一次重申,不存在潲水油问题。

成都的火锅还能吃吗?

记者:现在市民都很关心,成都火锅店安全吗?
李宏坤:成都火锅店是让人放心的。名单中的13家火锅店违规使用的不是有毒有害的油。按照《食品安全法》规定,成都的食品企业,经营时要查验供货商的检验报告,卫生部门长期以来要求餐饮业,包括火锅店进行凭证索票制度的建立。以后会把关,让餐饮业学会鉴别合法供货商。
黄生:这次对全市拉网检查,对市场的4000多户食用油经营户进行了检查,结果除了50户的部分品种没有QS标识外,没有发现其他问题。我负责任地告诉大家,成都市场销售的食用油,广大市民可放心食用。

为何之前政府没答复?

记者:本次事件媒体早有报道,为什么政府部门一直没答复?
周蓉:到27日才向媒体发通报,是因为需要调查取证。有些证据需要到山东滕州去取。这个过程中,各监管部门都要把有关搜查、勘验、取证工作做实在。

联合暗访

随机抽检5家店未发现“地沟油”

昨日,四川省食品安全协调委员会办公室、省工商局、省卫生执法总队、省监察厅4家单位联合执法,对市内5家火锅店的食用油进行了检查。在5家抽检火锅店中,没有发现“地沟油”及“没有质检报告的食用油”。

进门亮证件直奔后堂操作间

由于此次检查属于暗访,省监察厅也被邀请来监督执法部门的检查。从火锅店食用油的进货渠道、台账、油的质检报告、熬制过程到潲水油怎么处理,全部被检查。
上午10点,执法人员乘车出发。“去哪家店呢?”“生意好的大火锅店。”
10:30,一行人来到琴台路一家火锅店。一进大门,执法人员掏出了工作证,并向接待人员说明了来意。接待人员说:“请各位等等,我马上通知经理过来。”“不用了,我们先进去看看你们用的油。”说着,执法人员直接绕过大堂走进操作间。
火锅店的储货间里,堆着十几箱菜籽油及几桶香油。赶来的负责人一再强调,店里没有老油。当天剩下的潲水油,都有专门的公司进行回收。
随即,他们拿出了一份协议书。根据协议,双流华阳镇一家个体养猪户负责每天回收潲水油。其中一条写着:“回收的潲水只能用于喂养使用,不能用于其它用途。”
“你们去过这个人的养猪场没有?”
“去过的,大概有500头猪的样子。”

熬的什么油?边看边闻边问

11点,执法人员走进了琴台路另一家连锁火锅店。一进门,就直奔操作间。这家店的油,是用透明塑料袋装好的,每锅一包。工作人员说,油是由总公司统一配送的清油。负责回收这家火锅店潲水的,是“成都市城卫保污油处理公司”。
“有质检的检验报告。”操作间里,三口大锅里正在熬着油,锅面浮起一层油脂。执法人员仔细查看油的成色、闻油的味道。
“这个是什么油?”
“是牛油混着海椒熬的,锅底油。”正在掌勺的工作人员回答。
被检查的几家火锅店都能提供所用菜籽油、香油的购货单及厂家质检报告的复印件。而火锅店也与专门的养猪场签了协议,由其专门负责处理潲水油。每一步检查,监察厅工作人员均在一旁监督。