VisualThreat发布业界首款抵御汽车攻击的硬件防火墙

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享

在刚刚结束的SyScan360安全大会上,VisualThreat公司成功演示了如何利用WIFI对汽车进行劫持攻击的方法,同时展示了业界第一款用来抵御汽车黑客攻击的硬件防火墙。防火墙直接插在汽车OBD2接口上,能有效的阻止对汽车的CAN message攻击,包括之前在黑客大会,DEFCON等会议上采用的对汽车攻击的方式。

随着智能汽车时代的到来,汽车成为下一个攻击目标。尤其通过手机和汽车内部的通信,黑客可以利用蓝牙,WIFI,甚至2G/3G对汽车进行恶意攻击。
车联网安全由此成为移动安全一个新兴的市场。

7月30日,星期三 VisualThreat公司和AUTO HACK公共小组在加州montain view的Hacker Dojo 举办一次讲座,
内容有关汽车无线攻击和防火墙抵御方法。欢迎大家前来参加!

题目: Defense: Vehicle OBD2 Over-The-Air Attacks

讲座网址: http://www.meetup.com/Autohack/events/196267042/

Wednesday, July 30, 2014 7:00 PM to 8:15 PM
Location: Hacker Dojo, 599 Fairchild Dr., Mountain View, CA

Defense: Vehicle OBD2 Over-The-Air Attacks w/ Visual Threat

A host of vendors are now offering popular vehicle cloud-connected software and hardware. Loose security puts users at risk of compromised privacy and actual loss of vehicle control. In this talk, speakers from VisualThreat will show how to build the first CAN BUS firewall to defend against OBD auto attacks.

This will include reverse engineering OBD2 and CANBUS, a demo of remotely controlling a vehicle via mobile app (w/o DIY hardware), and presenting research findings on security vulnerabilities of current commercial vehicle-related mobile products.

(没有打分)

Gartner公布2014年十大信息安全技术

全球领先的信息技术研究和顾问公司Gartner近日公布了2014年十大信息安全技术,同时指出了这些技术对信息安全部门的意义。

 

Gartner副总裁兼院士级分析师Neil MacDonald表示:“企业正投入越来越多的资源以应对信息安全与风险。尽管如此,攻击的频率与精密度却越来越高。高阶锁定目标的攻击与软件中的安全漏洞,让移动化、云端、社交与大数据所产生的“力量连结(Nexus of Forces)”在创造全新商机的同时也带来了更多令人头疼的破坏性问题。伴随着力量连结商机而来的是风险。负责信息安全与风险的领导者们必须全面掌握最新的科技趋势,才能规划、达成以及维护有效的信息安全与风险管理项目,同时实现商机并管理好风险。“

 

十大信息技术分别为:

 

云端访问安全代理服务(Cloud Access Security Brokers

云端访问安全代理服务是部署在企业内部或云端的安全策略执行点,位于云端服务消费者与云端服务供应商之间,负责在云端资源被访问时套用企业安全策略。在许多案例中,初期所采用的云端服务都处于IT掌控之外,而云端访问安全代理服务则能让企业在用户访问云端资源时加以掌握及管控。

 

适应性访问管控(Adaptive Access Control

适应性访问管控一种情境感知的访问管控,目的是为了在访问时达到信任与风险之间的平衡,结合了提升信任度与动态降低风险等技巧。情境感知(Context awareness)是指访问的决策反映了当下的状况,而动态降低风险则是指原本可能被封锁的访问可以安全的开放。采用适应性访问管理架构可让企业提供不限设备、不限地点的访问,并允许社交账号访问一系列风险程度不一的企业资产。

 

 

全面沙盒分析(内容引爆)与入侵指标(IOC)确认

无可避免地,某些攻击将越过传统的封锁与安全防护机制,在这种情况下,最重要的就是要尽可能在最短时间内迅速察觉入侵,将黑客可能造成的损害或泄露的敏感信息降至最低。许多信息安全平台现在都具备在虚拟机(VM)当中运行(亦即“引爆”)执行档案和内容的功能,并且能够观察VM当中的一些入侵指标。这一功能已迅速融入一些较强大的平台当中,不再属于独立的产品或市场。一旦侦测到可疑的攻击,必须再通过其他不同层面的入侵指标进一步确认,例如:比较网络威胁侦测系统在沙盒环境中所看到的,以及实际端点装置所观察到的状况(包括:活动进程、操作行为以及注册表项等)。

 

端点侦测及回应解决方案

端点侦测及回应(EDR)市场是一个新兴市场,目的是为了满足端点(台式机、服务器、平板与笔记本)对高阶威胁的持续防护需求,最主要是大幅提升安全监控、威胁侦测及应急响应能力。这些工具记录了数量可观的端点与网络事件,并将这些信息储存在一个集中地数据库内。接着利用分析工具来不断搜寻数据库,寻找可提升安全状态并防范一般攻击的工作,即早发现持续攻击(包括内部威胁),并快速响应这些攻击。这些工具还有助于迅速调查攻击范围,并提供补救能力。

 

新一代安全平台核心:大数据信息安全分析

未来,所有有效的信息安全防护平台都将包含特定领域嵌入式分析核心能力。一个企业持续监控所有运算单元及运算层,将产生比传统SIEM系统所能有效分析的更多、更快、更多元的数据。Gartner预测,至2020年,40%的企业都将建立一套“安全数据仓库”来存放这类监控数据以支持回溯分析。籍由长期的数据储存于分析,并且引入情境背景、结合外部威胁与社群情报,就能建立起“正常”的行为模式,进而利用数据分析来发觉真正偏离正常的情况。

 

机器可判读威胁智能化,包含信誉评定服务

与外界情境与情报来源整合是新一代信息安全平台最关键的特点。市场上机器可判读威胁智能化的第三方资源越来越多,其中包括许多信誉评定类的选择。信誉评定服务提供了一种动态、即时的“可信度”评定,可作为信息安全决策的参考因素。例如,用户与设备以及URL和IP地址的信誉评定得分就可以用来判断是否允许终端用户进行访问。

 

以遏制和隔离为基础的信息安全策略

在特征码(Signatures)越来越无法阻挡攻击的情况下,另一种策略就是将所有未知的都当成不可信的,然后在隔离的环境下加以处理并运行,如此就不会对其所运行的系统造成永久损害,也不会将该系统作为矢量去攻击其他企业系统。虚拟化、隔离、提取以及远程显示技术,都能用来建立这样的遏制环境,理想的结果应与使用一个“空气隔离”的独立系统来处理不信任的内容和应用程序一样。虚拟化与遏制策略将成为企业系统深度防御防护策略普遍的一环,至2016年达到20%的普及率,一改2014年几乎未普遍采用的情况。

 

软件定义的信息安全

所谓的“软件定义”是指当我们将数据中心内原本紧密耦合的基础架构元素(如服务器、存储、网络和信息安全等等)解离并提取之后所创造的能力。如同网络、计算与存储的情况,对信息安全所产生的影响也将发生变化。软件定义的信息安全并不代表不再需要一些专门的信息安全硬件,这些仍是必不可少的。只不过,就像软件定义的网络一样,只是价值和智能化将转移到软件当中而已。

 

互动式应用程序安全测试

互动式应用程序安全测试(IAST)将静态应用程序安全测试(SAST)与动态应用程序安全测试(DAST)技术进行结合。其目的是要通过SAST与DAST技术之间的互动以提升应用程序安全测试的准确度。IAST集合了SAST与DAST最好的优点于一单一解决方案。有了这套方法,就能确认或排除已侦测到的漏洞是否可能遭到攻击,并判断漏洞来源在应用程序代码中的位置。

 

针对物联网的安全网关、代理与防火墙

企业都有一些设备制造商所提供的运营技术(OT),尤其是一些资产密集型产业,如制造业与公共事业,这些运营技术逐渐从专属通信与网络转移至标准化网际网络通信协议(IP)技术。越来越多的企业资产都是利用以商用软件产品为基础的OT系统进行自动化。这样的结果是,这些嵌入式软件资产必须受到妥善的管理、保护及配发才能用于企业级用途。OT被视为产业界的“小物联网”,其中涵盖数十亿个彼此相连的感应器、设备与系统,许多无人为介入就能彼此通信,因此必须受到保护与防护。

(没有打分)

大数据计算新贵Spark在腾讯雅虎优酷成功应用解析

Spark作为Apache顶级的开源项目,项目主页见http://spark.apache.org。在迭代计算,交互式查询计算以及批量流计算方面都有相关的子项目,如Shark、Spark Streaming、MLbase、GraphX、SparkR等。从13年起Spark开始举行了自已的Spark Summit会议,会议网址见http://spark-summit.org。Amplab实验室单独成立了独立公司Databricks来支持Spark的研发。

为了满足挖掘分析与交互式实时查询的计算需求,腾讯大数据使用了Spark平台来支持挖掘分析类计算、交互式实时查询计算以及允许误差范围的快速查询计算,目前腾讯大数据拥有超过200台的Spark集群,并独立维护Spark和Shark分支。Spark集群已稳定运行2年,我们积累了大量的案例和运营经验能力,另外多个业务的大数据查询与分析应用,已在陆续上线并稳定运行。在SQL查询性能方面普遍比MapReduce高出2倍以上,利用内存计算和内存表的特性,性能至少在10倍以上。在迭代计算与挖掘分析方面,精准推荐将小时和天级别的模型训练转变为Spark的分钟级别的训练,同时简洁的编程接口使得算法实现比MR在时间成本和代码量上高出许多。

Spark VS MapReduce

尽管MapReduce适用大多数批处理工作,并且在大数据时代成为企业大数据处理的首选技术,但由于以下几个限制,它对一些场景并不是最优选择:

 

  • 缺少对迭代计算以及DAG运算的支持
  • Shuffle过程多次排序和落地,MR之间的数据需要落Hdfs文件系统

 

Spark在很多方面都弥补了MapReduce的不足,比MapReduce的通用性更好,迭代运算效率更高,作业延迟更低,它的主要优势包括:

 

  • 提供了一套支持DAG图的分布式并行计算的编程框架,减少多次计算之间中间结果写到Hdfs的开销
  • 提供Cache机制来支持需要反复迭代计算或者多次数据共享,减少数据读取的IO开销
  • 使用多线程池模型来减少task启动开稍,shuffle过程中避免不必要的sort操作以及减少磁盘IO操作
  • 广泛的数据集操作类型

 

MapReduce由于其设计上的约束只适合处理离线计算,在实时查询和迭代计算上仍有较大的不足,而随着业务的发展,业界对实时查询和迭代分析有更多的需求,单纯依靠MapReduce框架已经不能满足业务的需求了。Spark由于其可伸缩、基于内存计算等特点,且可以直接读写Hadoop上任何格式的数据,成为满足业务需求的最佳候选者。

应用Spark的成功案例

目前大数据在互联网公司主要应用在广告、报表、推荐系统等业务上。在广告业务方面需要大数据做应用分析、效果分析、定向优化等,在推荐系统方面则需要大数据优化相关排名、个性化推荐以及热点点击分析等。

这些应用场景的普遍特点是计算量大、效率要求高。Spark恰恰满足了这些要求,该项目一经推出便受到开源社区的广泛关注和好评。并在近两年内发展成为大数据处理领域最炙手可热的开源项目。

本章将列举国内外应用Spark的成功案例。

1. 腾讯

广点通是最早使用Spark的应用之一。腾讯大数据精准推荐借助Spark快速迭代的优势,围绕“数据+算法+系统”这套技术方案,实现了在“数据实时采集、算法实时训练、系统实时预测”的全流程实时并行高维算法,最终成功应用于广点通pCTR投放系统上,支持每天上百亿的请求量。

基于日志数据的快速查询系统业务构建于Spark之上的Shark,利用其快速查询以及内存表等优势,承担了日志数据的即席查询工作。在性能方面,普遍比Hive高2-10倍,如果使用内存表的功能,性能将会比Hive快百倍。

2. Yahoo

Yahoo将Spark用在Audience Expansion中的应用。Audience Expansion是广告中寻找目标用户的一种方法:首先广告者提供一些观看了广告并且购买产品的样本客户,据此进行学习,寻找更多可能转化的用户,对他们定向广告。Yahoo采用的算法是logistic regression。同时由于有些SQL负载需要更高的服务质量,又加入了专门跑Shark的大内存集群,用于取代商业BI/OLAP工具,承担报表/仪表盘和交互式/即席查询,同时与桌面BI工具对接。目前在Yahoo部署的Spark集群有112台节点,9.2TB内存。

3. 淘宝

阿里搜索和广告业务,最初使用Mahout或者自己写的MR来解决复杂的机器学习,导致效率低而且代码不易维护。淘宝技术团队使用了Spark来解决多次迭代的机器学习算法、高计算复杂度的算法等。将Spark运用于淘宝的推荐相关算法上,同时还利用Graphx解决了许多生产问题,包括以下计算场景:基于度分布的中枢节点发现、基于最大连通图的社区发现、基于三角形计数的关系衡量、基于随机游走的用户属性传播等。

4. 优酷土豆

优酷土豆在使用Hadoop集群的突出问题主要包括:第一是商业智能BI方面,分析师提交任务之后需要等待很久才得到结果;第二就是大数据量计算,比如进行一些模拟广告投放之时,计算量非常大的同时对效率要求也比较高,最后就是机器学习和图计算的迭代运算也是需要耗费大量资源且速度很慢。

最终发现这些应用场景并不适合在MapReduce里面去处理。通过对比,发现Spark性能比MapReduce提升很多。首先,交互查询响应快,性能比Hadoop提高若干倍;模拟广告投放计算效率高、延迟小(同hadoop比延迟至少降低一个数量级);机器学习、图计算等迭代计算,大大减少了网络传输、数据落地等,极大的提高的计算性能。目前Spark已经广泛使用在优酷土豆的视频推荐(图计算)、广告业务等。

Spark与Shark的原理

1.Spark生态圈

如下图所示为Spark的整个生态圈,最底层为资源管理器,采用Mesos、Yarn等资源管理集群或者Spark自带的Standalone模式,底层存储为文件系统或者其他格式的存储系统如HBase。Spark作为计算框架,为上层多种应用提供服务。Graphx和MLBase提供数据挖掘服务,如图计算和挖掘迭代计算等。Shark提供SQL查询服务,兼容Hive语法,性能比Hive快3-50倍,BlinkDB是一个通过权衡数据精确度来提升查询晌应时间的交互SQL查询引擎,二者都可作为交互式查询使用。Spark Streaming将流式计算分解成一系列短小的批处理计算,并且提供高可靠和吞吐量服务。

2.Spark基本原理

Spark运行框架如下图所示,首先有集群资源管理服务(Cluster Manager)和运行作业任务的结点(Worker Node),然后就是每个应用的任务控制结点Driver和每个机器节点上有具体任务的执行进程(Executor)。

与MR计算框架相比,Executor有二个优点:一个是多线程来执行具体的任务,而不是像MR那样采用进程模型,减少了任务的启动开稍。二个是Executor上会有一个BlockManager存储模块,类似于KV系统(内存和磁盘共同作为存储设备),当需要迭代多轮时,可以将中间过程的数据先放到这个存储系统上,下次需要时直接读该存储上数据,而不需要读写到hdfs等相关的文件系统里,或者在交互式查询场景下,事先将表Cache到该存储系统上,提高读写IO性能。另外Spark在做Shuffle时,在Groupby,Join等场景下去掉了不必要的Sort操作,相比于MapReduce只有Map和Reduce二种模式,Spark还提供了更加丰富全面的运算操作如filter,groupby,join等。

Spark采用了Scala来编写,在函数表达上Scala有天然的优势,因此在表达复杂的机器学习算法能力比其他语言更强且简单易懂。提供各种操作函数来建立起RDD的DAG计算模型。把每一个操作都看成构建一个RDD来对待,而RDD则表示的是分布在多台机器上的数据集合,并且可以带上各种操作函数。如下图所示:

首先从hdfs文件里读取文本内容构建成一个RDD,然后使用filter()操作来对上次的RDD进行过滤,再使用map()操作取得记录的第一个字段,最后将其cache在内存上,后面就可以对之前cache过的数据做其他的操作。整个过程都将形成一个DAG计算图,每个操作步骤都有容错机制,同时还可以将需要多次使用的数据cache起来,供后续迭代使用。

3.Shark的工作原理

Shark是基于Spark计算框架之上且兼容Hive语法的SQL执行引擎,由于底层的计算采用了Spark,性能比MapReduce的Hive普遍快2倍以上,如果是纯内存计算的SQL,要快5倍以上,当数据全部load在内存的话,将快10倍以上,因此Shark可以作为交互式查询应用服务来使用。

上图就是整个Shark的框架图,与其他的SQL引擎相比,除了基于Spark的特性外,Shark是完全兼容Hive的语法,表结构以及UDF函数等,已有的HiveSql可以直接进行迁移至Shark上。

与Hive相比,Shark的特性如下:

1.以在线服务的方式执行任务,避免任务进程的启动和销毁开稍,通常MapReduce里的每个任务都是启动和关闭进程的方式来运行的,而在Shark中,Server运行后,所有的工作节点也随之启动,随后以常驻服务的形式不断的接受Server发来的任务。

2.Groupby和Join操作不需要Sort工作,当数据量内存能装下时,一边接收数据一边执行计算操作。在Hive中,不管任何操作在Map到Reduce的过程都需要对Key进行Sort操作。

3.对于性能要求更高的表,提供分布式Cache系统将表数据事先Cache至内存中,后续的查询将直接访问内存数据,不再需要磁盘开稍。

4.还有很多Spark的特性,如可以采用Torrent来广播变量和小数据,将执行计划直接传送给Task,DAG过程中的中间数据不需要落地到Hdfs文件系统。

腾讯大数据Spark的概况

腾讯大数据综合了多个业务线的各种需求和特性,目前正在进行以下工作:

1.经过改造和优化的Shark和Spark吸收了TDW平台的功能,如Hive的特有功能:元数据重构,分区优化等,同时可以通过IDE或者洛子调度来直接执行HiveSql查询和定时调度Spark的任务;

2.与Gaia和TDW的底层存储直接兼容,可以直接安全且高效地使用TDW集群上的数据;

3.对Spark底层的使用门槛,资源管理与调度,任务监控以及容灾等多个功能进行完善,并支持快速的迁移和扩容。

(没有打分)

TSRC:主流WAF架构分析与探索

TSRC:主流WAF架构分析与探索

7926fbadf82eead3fe9292b646899103

背景:

网站安全漏洞在被发现后,需要修复,而修复需要时间,有些厂商可能无能力修复,甚至部分网站主可能连是否存在漏洞都无法感知(尤其是攻击者使用0day的情况下)。或者刚公开的1day漏洞,厂商来不及修复,而众多黑客已经掌握利用方法四面出击,防不胜防。这个时候如果有统一集中的网站防护系统(WAF)来防护,则漏洞被利用的风险将大大降低,同时也为漏洞修复争取时间!

笔者所在公司的业务较多,光域名就成千上万,同时网络流量巨大,动辄成百上千G。而这些业务部署在数十万台服务器上,管理运维职能又分散在数十个业务部门,安全团队不能直接的管理运维。在日常的安全管理和对抗中,还会经常性或者突发性的遇到0day需要响应,比如更新检测引擎的功能和规则,这些都是比较现实的挑战。

对于WAF的实现,业界知名的网站安全防护产品也各有特色。本文将对主流的WAF架构做一个简单的介绍,和大家分享下。同时结合笔者所在公司业务的实际情况,采用了一种改进方案进行探索,希望本文能达到抛砖引玉的效果。(不足之处请各位大牛多多指教)

特别声明:以下方案无优劣之分,仅有适合不适合业务场景的区别。

业界常见网站安全防护方案

方案A:本机服务器模块模式

通过在Apache,IIS等Web服务器内嵌实现检测引擎,所有请求的出入流量均先经过检测引擎的检测,如果请求无问题则调用CGI处理业务逻辑,如果请求发现攻击特征,再根据配置进行相应的动作。以此对运行于Web服务器上的网站进行安全防护。著名的安全开源项目ModSecurity及naxsi防火墙就是此种模式。

优点:

1、 网络结构简单,只需要部署Web服务器的安全模块

挑战:

1、 维护困难。当有大规模的服务器集群时,任何更新都涉及到多台服务器。

2、 需要部署操作,在面临大规模部署时成本较高。

3、 无集中化的数据中心。针对安全事件的分析往往需要有集中式的数据汇总,而此种模式下用户请求数据分散在各个Web服务器上。

方案B:反向代理模式

使用这种模式的方案需要修改DNS,让域名解析到反向代理服务器。当用户向某个域名发起请求时,请求会先经过反向代理进行检测,检测无问题之后再转发给后端的Web服务器。这种模式下,反向代理除了能提供Web安全防护之外,还能充当抗DDoS攻击,内容加速(CDN)等功能。云安全厂商CloudFlare采用这种模式。

优点:

1、 集中式的流量出入口。可以针对性地进行大数据分析。

2、 部署方便。可多地部署,附带提供CDN功能。

挑战:

1、 动态的额外增加一层。会带来用户请求的网络开销等。

2、 站点和后端Web服务器较多的话,转发规则等配置较复杂。

3、 流量都被捕捉,涉及到敏感数据保护问题,可能无法被接受。

方案C:硬件防护设备

这种模式下,硬件防护设备串在网络链路中,所有的流量经过核心交换机引流到防护设备中,在防护设备中对请求进行检测,合法的请求会把流量发送给Web服务器。当发现攻击行为时,会阻断该请求,后端Web服务器无感知到任何请求。防护设备厂商如imperva等使用这种模式。

优点:

1、 对后端完全透明。

挑战:

1、 部署需改变网络架构,额外的硬件采购成本。

2、 如Web服务器分布在多个IDC,需在多个IDC进行部署。

3、 流量一直在增加,需考虑大流量处理问题。以及流量自然增长后的升级维护成本。

4、 规则依赖于厂商,无法定制化,不够灵活。

我们的探索

笔者所在的公司在不同的场景下,也近似的采纳了一种或者多种方案的原型加以改进使用运营。(比如方案C,其实我们也有给力的小伙伴做了很棒的努力,通过自研的方式解决了不少挑战,以后有机会或许也会和大家分享一些细节)

今天给大家介绍的,是我们有别于业界常见模型的一种思路:

方案D:服务器模块+检测云模式

这种模式其实是方案A的增强版,也会在Web服务器上实现安全模块。不同点在于,安全模块的逻辑非常简单,只是充当桥梁的作用。检测云则承担着所有的检测发现任务。当安全模块接收到用户的请求时,会通过UDP或者TCP的方式,把用户请求的HTTP文本封装后,发送到检测云进行检测。当检测无问题时,告知安全模块把请求交给CGI处理。当请求中检测到攻击特征时,则检测云会告知安全模块阻断请求。这样所有的逻辑、策略都在检测云端。

我们之所以选择这个改进方案来实现防护系统,主要是出于以下几个方面的考虑:

1、       维护问题

假如使用A方案,当面临更新时,无法得到及时的响应。同时,由于安全逻辑是嵌入到Web服务器中的,任何变更都存在影响业务的风险,这是不能容忍的。

2、       网络架构

如果使用方案B,则需要调动大量的流量,同时需要提供一个超大规模的统一接入集群。而为了用户就近访问提高访问速度,接入集群还需要在全国各地均有部署,对于安全团队来说,成本和维护难度难以想象。

使用该方案时,需要考虑如下几个主要的挑战:

1、       网络延时

采用把检测逻辑均放在检测云的方式,相对于A来说,会增加一定的网络开销。不过,如果检测云放在内网里,这个问题就不大,99%的情况下,同城内网发送和接收一个UDP包只需要1ms。

2、       性能问题:

由于是把全量流量均交给集中的检测云进行检测,大规模的请求可能会带来检测云性能的问题。这样在实现的时候就需要设计一个好的后端架构,必须充分考虑到负载均衡,流量调度等问题。

3、       部署问题:

该方案依然需要业务进行1次部署,可能会涉及到重编译web服务器等工作量,有一定的成本。并且当涉及到数千个域名时,问题变的更为复杂。可能需要区分出高危业务来对部署有一个前后顺序,并适时的通过一些事件来驱动部署。

最后,我们目前已灰度上线了这套防御方案,覆盖重要以及高危的业务站点。目前日均处理量约数百亿的规模,且正在快速增长阶段。

本文只是一个粗略的简介,我们在建设过程中也遇到了远高于想象的挑战和技术难题,后续将会有系列文章来深入剖析和介绍,希望对大家有所帮助。

作者:腾讯安全应急响应中心 那个谁

(没有打分)

A Guide to NFV and SDN

(没有打分)

Jaguar Land Rover开发自主学习智能车

原文译自:TheHindu.com

印度塔塔集团旗舰车品牌Jaguar Land Rover(可以翻成捷豹路虎?)研发中的智能车能够提供个性化驾驶体验,通过提高驾驶者注意力来帮助减少事故的发生。
使用前沿的机器学习与人工智能技术,JLR推出的智能车能够判断驾驶者身份,学习驾驶者的喜好和驾驶习惯,从而为驾驶者提供个性化的服务。
软件通过录入日期,交通状况,天气等变量来估测驾驶动作,使驾驶者能绕过驾驶中需要注意的繁琐细节,专注于前方道路。
JLR科研主管Wolfgang Epple说:“我们的自主学习技术意在减少驾驶者分心,从而降低交通事故的风险。我们的智能车可以在适当的时间提供适当的信息,驾驶者不用去翻通讯录,不用操心调整车镜,温度,座椅的位置。这使得驾驶者更不容易分心。”
Epple补充说:“目前多数智能车把焦点集中在交通和导航的预测方面,而我们想要向前推进一步,让我们的学习算法更多地关注从驾驶者身上获取信息,并通过个性化驾驶体验来提高驾驶的快感。”
智能车在驾驶者打开车门时通过智能手机识别驾驶者身份,车镜,方向盘,座椅设置都将根据驾驶者的个人喜好被设置妥当。驾驶室的温度将会被预置为用户想要的温度,并且会根据天气情况自动调节。
通过智能助手,智能车还能够分析你的日程,并根据交通情况预设导航以避免拥堵。智能助手还能根据日程判断下一个目的地。
如果你的目的地是健身房,系统还会通过学习,在去的路上使车辆达到热身的温度,在离开健身房调整到较为凉爽的温度。该智能车还能在不同路况,交通状况下学习驾驶者的驾驶习惯。
Epple表示:“通过开发具有学习功能的自适应续航控制系统,在属于自动驾驶车的下一个十年里,智能车将继续保持其趣味性及价值。”

(没有打分)

机器学习应用–切影片尿点

原文来自:Business Insider

Just about every device has a camera in it, so we’re shooting more and more video than we have ever before. If only all of it were worth watching.

The latest application of machine learning was developed by Eric P. Xing, professor of machine learning from Carnegie Mellon University, and Bin Zhao, a Ph.D. student in the Machine Learning Department. It’s called LiveLight, and it can help automate the reduction of videos to just their good parts.

LiveLight takes a long piece of source footage and “evaluates action in the video, looking for visual novelty and ignoring repetitive or eventless sequences, to create a summary that enables a viewer to get the gist of what happened.” Put another way, it watches your movie and edits out the boring stuff. This all happens with just one pass through said video — LiveLight never works backwards.

You’re left with something more like a highlight reel than the too-long original video pictured on the left above. LiveLight is robust enough to run on a standard laptop and is powerful enough to process an hour of video in one or two hours.

(1个打分, 平均:4.00 / 5)

The Mathematics of Romance (2):Same you, while attractive to more

The Mathematics of Romance (2):Same you, while attractive to more

副标题:头像那些事儿

废话不多说:这是个看脸的社会。

社交网站(屌丝级的新浪微博,或意识形态上高攀不起的Facebook or Twitter),求职网站(这个……),还有相亲网站……好像很难想到一个不需要上传头像(或personal profile)的网络服务。而彩笔都很难记清,从什么时候开始,人类(或具体地说祖国人民)进入网络时代,男女老少逐渐都有了自己难以割舍的网络服务。

对任何(正常)人来说,无论什么情境下的头像,都是一个展示自己的渠道。展示自己长得好看,展示自己逼格很高,展示自己的人生理想,展示自己的三观。

展示的目的是吸引。不知道“正常”的人们都怎么看,“吸引”在彩笔看来是个很暧昧的词儿。当“相互吸引”关系确立时,后面的事情就不好说了。但无论如何都是很有趣的事情,你值得拥有哦。

插注:前面一段话实质上与本文、大数据关系不大,但因彩笔坚信“文以言志”,而彩笔的是传递价值观,所以这些内容也不是完全没有必要。

 

本文关于头像选择,更具体的说,是相亲网站用户的头像选择(不负责任一点地说,社交网站也是类似的逻辑吧)——因为原始数据来自相亲网站的用户(看过preliminary的读者应该知道了)。

我想,所有人都会不同程度的同意下面这句话:

No matter how much time you spend polishing your profile, honing your IM banter, and perfecting your message introductions, IT’S YOUR PICTURE THAT MATTERS MOST.

 

一、谁敢说自己“不看脸”

这就是一个看脸的社会,don’t deny it。(我又没说只看脸)

1. 对异性的评价与挑选目标

旁白:题目中的评价挑选并不矛盾。假设所有人都给章子怡5分(满分5分)(此之谓评价),但并非所有人在挑选去民政局登记的对象的时候,均是以子怡为首选(此之谓定制目标)。弱水三千,只取一瓢饮,这里无需多言吧。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

两张图中的虚线表示的是各个性别群体对异性的评价分布(数据来源及操作方法将在文章结尾处尽表)。粗实线表示的是他们/她们向异性发送消息的比例分布。

从图中可以看出,男性对女性的(整体)评价(左图虚线)接近对称,但是在挑选“目标”的时候他们的倾向性非常明显(还需要彩笔明说嘛[捂嘴笑])。女性对男性的评价分布(右图)用“苛刻”来形容毫不为过。大多数(80%)男性在她们看来是worse-looking than medium,然而在选择发送信息的对象时,她们又变得宽容。

产生这种差异的原因值得玩味,但不在此处细表。图中的数据似乎是在告诉我们:不管长成什么样(异性对“你”的评价如何)都会收到信息(在这篇文章中,彩笔不想纠结群体与个体的关系——群体有并不代表群体中的每个个体都有)。而在本文中,我们用到的信息是:对于女孩子,头像中的你长得越漂亮,收到的信息就越多;男性的话,好难讲,彩笔一直觉得女性从男性那里寻求的并非“美颜”,所以才会出现上图中的神奇分布,但至少头像中的形象能让女性找到她们寻求的某样东西或某种感觉。

 

2. 数量化ATTRACTIVENESS

之前说到,头像在异性们心目中的好看程度与最终收到的信息数量是有关系的,并且按照“常理”,越好看的人收到的信息数量就越多(姑且忽略男女两性在对对方评价以及最终挑选目标时的差异)。

 

 

 

 

 

 

 

 

 

 

 

图中的信息呼之欲出:长相(头像)越好看的人,收到的信息越多(注意:纵坐标是“倍数”,而非绝对数量哦)。Female recipients的曲线斜率的增加速度快过male recipients——原来我们的小伙子们都是行动派嘛。

对于任何一个读到这里的读者,在此刻可以确认头像的重要性了吧。

 

3. 成功率与头像(长相)

前面讲的都是作为一个被动的receiver,头像与接收到的求*信息数量的关系。这一节中,展示的是作为sender,信息被回复(即“求*初步成功”)与头像的关系。长得好看的人收到的信息越多,那么发出的求*信息的成功率(被回复)是否也越高呢?请看下图。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

根据图表中的信息,说“越好看的人发出去的信息成功率越高”好像可以,但也好像有点牵强。Most attractive male senders在least attractive female recipients会遇到点挫折呢。不过还好,总的来说,也是“越好看,成功率就越高”的啦(如下图)。然后姑娘的成功率弱弱的高于小伙子们(果然,在社会大家庭中,蓝孩纸还是很照顾铝孩纸的)。

 

 

 

 

 

 

 

 

 

 

 

 

二、选头像时的does and don’ts

人就长成这无法被拯救的样子了,但是头像还是可以挽回一些的。能挽回多少?就看你怎么玩儿了~

1. FACIAL ATTITUDE

头像中的表情与每月新增联系人的数量关系如下。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

从图中可以看出,对于女生来说,笑比不笑的效果(吸引力)好,但是效果最好的头像表情是flirty-face。但要注意flirty face要对着镜头,如果没对镜头的话,可能会是相反的作用。男生的情况相对简单了:look away from the camera and don’t smile。

 

2. The MySpace Angle is busted.

The universally-maligned MySpace angle is achieved by holding your camera above your head and being just so darn coy.——我大中华的仰拍什么的,原来在异国他乡是有名字的啊!

 

 

 

 

 

 

这种自拍类照片往往是头像界所不齿的类型,然而,它在吸引新联系人(女性吸引男性)方面有着意料之外的正面效果,如下图。

 

 

 

 

 

 

 

 

 

 

 

 

这让研究人员百思不得其解,the Myspace shot对于女性来说几乎是唯一一种有效的照片类型。研究人员怀疑过,是否是因为这样的角度能够获得从上往下看女生上衣的角度(这么说十分隐晦,不过……应该能懂吧)。但当研究者将所有“能看到”的照片剔除,重复分析,得到的结果是一样的。甚至,the Myspace shot的效果还要好于直接“露”,嗯。

 

3. Guys should keep their shirts on.

同样与人类常识相反的是“男生秀腹肌”。在人们的印象中,Ab shot通常让人觉得PO主很二。然而实际的情况是这样的:

 

 

 

 

 

 

 

 

 

 

 

研究人员认为产生这种现象的原因是:Normally,将此类照片作为头像的人都有show off的资本,and naturally the best bodies get lots of messages。但是,如果是这个原因让这类照片火了的话,这个举措就不适合推荐给所有男士了哦。

 

4. Make sure your face is showing(?)

OkCupid过去是将露脸作为推荐项(强制项)出现在用户提交personal profile的页面的,然而in fact, not showing your face can be a positive, as long as you substitute in something unusual, sexy, or mysterious enough to make people want to talk to you.成功的例子如下:

 

 

 

 

 

 

 

 

 

 

 

这些用户收到的信息数远高于一般水平,但他们并没有很出众的个人介绍,正是他们的头像帮助他们达成了这样的效果。

写到这里,好像又与初衷矛盾了——不是说,这是个看脸的社会么?我想这个问题大家随意思考一下就可以了,无需彩笔给出一个答案(或答案之一)。而且我在最开始的时候就说过了:我又没说“只”看脸。

 

数据来源与操作方法

The data set was chosen at random from all users in big cities, with only one profile photograph, between the ages of 18 and 32. We then lopped the most and least attractive members of the pool, fearing that they would skew our results. So all the data in this post is for “average-looking people.”

 

We finalized our data pool at 7,140 users. Aside from running each picture through a variety of analysis scripts, we tagged, by hand, each picture for various contextual indicators. We double-checked the tags before generating our data.

 

To quantify “profile success” for women, we used new messages received per active month on the site.

 

We had to do something different than this for guys, because of the fundamentally different role they play in the online courtship process: they are the ones reaching out to new people; women send only a small fraction of the unsolicited “hellos” that men do. As you’ve seen, the metric we settled on is, “women met per attempt”, which is:

(new incoming messages + replies to outgoing first contacts) / outgoing first contacts

 

Basically, this is how many women a guy has a conversation with, per new woman he reaches out to, and we feel it’s the best way to measure his success per unit time on OkCupid. Note that if a guy has a particularly compelling photo, this ratio could exceed 1, as he’d be getting messages from the women who come across his profile, as well as the women he himself is reaching out to.

 

总结

多么有意思的结论。而且,是这么多有意思的结论。

不曾跟进过笔者其他文章的读者是否压根看不到这里:这跟大数据有半毛钱关系?!

其实此时此刻的彩笔根本压抑不住内心的狂热,想要大声告诉任何人:在有“大数据”(好吧,彩笔必须承认,这里的大数据定义有些模糊)之前,这些事情是无法做到的。——虽然其实不是,或者彩笔也不能确定的知道是或者不是。

 

在系列“GFT你这么diao,你的伪粉丝们造吗”最后一篇文章的结尾,笔者提出,GFT内生的一个drawback是:GFT自身是大数据的一套方法体系,然而它却是为预测一个由传统的统计方法得到的数据而存在的。在这种交错中,没有人知道伴生着什么问题(影响预测的准确性,或者对“准确性”的解读)。

在Lazer的文章[1]中也给出建议:Google可以通过combine big data and small data来优化预测过程。笔者认为,OKCUPID的这群研究人员做到了,或者说做了很好的尝试。

这个研究团队的主要成员已经在本系列的第一篇文章(约2个月前[惭愧])中有过简单介绍。

关于头像,他们在证明头像中人物的“质量”与收到陌生人信息的数量之间的相关关系甚至数量关系的基础上[参考文章6],还总结了拍摄照片的技巧[参考文章4](当然是以吸引力为衡量标准)以及头像内容与吸引力[参考文章3](收到陌生人信息数量)的关系,另外还从男性心理的角度出发,指导女性选择头像[参考文章2]。作为成果之一,他们还一度提供一项帮你判断哪张照片更适合作为头像的服务[参考文章5]。

作为一个基于online dating网站的研究团队,他们的兴趣内容还涉及发给对方的第一句话怎么说更容易收到回复?第一次约会怎样操作更容易lead to下一次?等等。

按照国内学术圈的惯用标准,既有科学意义,又有实践意义,“业界良心”好好嘛!

 

另注:

这真的是一篇关于大数据的文章(很难理解么)。之前的系列“the Big Data Concerns You HOW”出街之后,相信仍然会有不死心人士。本文提到的这类“工作”的门槛低,成就高(我就随口说说而已,哪有这么容易的事),不失为一个很好的切入角度。

这真的是一篇关于大数据的文章,所以我没有任何念头教读者如何选头像。将原科研人员的数据来源以及预处理过程交代清楚,其目的除了将原作拖下神坛,方便更多的不死心人士踩踏入门之外。另外一个目的也是告诉读者,这虽然是一个“大数据案例”,但也有其内源性的适用对象。虽然,作为参考而借鉴是没什么的。

——在这里也要深刻反思对“大数据”的界定模糊。

 

相关文献:

[1] Lazer D, Kennedy R, King G, et al. The Parable of Google Flu: Traps in Big Data Analysis[J]. Science, 2014, 343(6176): 1203-1205.

[2] The Mathematics of Beauty, 2011.01.10, Christian Rudder:http://blog.okcupid.com/index.php/the-mathematics-of-beauty/

微信公众账号《数据分析》的一篇文章基本算是原文的译文,但是没有标注任何引用,着实可耻:

大数据分析看如何成为美人。[八卦]2014.04.18:mp.weixin.qq.com/s?__biz=MjM5MjAxMDM4MA==&mid=200226343&idx=1&sn=714db607d786fab9504080fc4617815c#rd

[3] The 4 Big Myths of Profile Pictures, 2010.01.20, Christian Rudder, http://blog.okcupid.com/index.php/the-4-big-myths-of-profile-pictures/

[4] Don’t Be Ugly by Accident, 2010.08.10, Christian Rudder, http://blog.okcupid.com/index.php/dont-be-ugly-by-accident/

[5] What Is Your Best Profile Picture, 2010.05.06, Christian Rudder, http://blog.okcupid.com/index.php/my-best-face/

[6] Your Looks and Your Inbox, 2009.11.17, Christian Rudder, http://blog.okcupid.com/index.php/your-looks-and-online-dating/

(1个打分, 平均:5.00 / 5)

大数据 。社会医疗健康

(没有打分)

美国白宫 。大数据 。《BIG DATA: SEIZING OPPORTUNITIES, PRESERVING VALUES》

(没有打分)