Facebook has rolled out its facial recognition technology to countries outside of the US, but has switched the feature on by default without telling its users first.
UK-based security expert Graham Cluely noted earlier today that Facebook had slotted the tech into the social network.
The Mark Zuckerberg-run company started using its facial recognition software in December last year for its Stateside users in a move to automatically provide tags for the photos uploaded by Facebook users.
The tech works by scanning newly uploaded pics and then identifies faces from previously tagged photos already stored in Zuckerberg’s internet silo.
When the software was introduced in the US late last year, Facebook pointed out that users could disable the function.
“If for any reason you don’t want your name to be suggested, you will be able to disable suggested tags in your Privacy Settings,”
the company wrote on its blog post last December.
But now that the tech has reached other shores, Facebook clearly didn’t feel the need to alert its international stalkerbase that its facial recognition software had been switched on by default within the social network.
The “Suggest photos of me to friends” feature in question is located in the company’s privacy settings. Facebookers need to click on “customise settings” before being able to access the function and disable it, if they so wish.
“Unfortunately, once again, Facebook seems to be sharing personal information by default.
Many people feel distinctly uncomfortable about a site like Facebook learning what they look like, and using that information without their permission,” said Cluley.
“Most Facebook users still don’t know how to set their privacy options safely, finding the whole system confusing.
It’s even harder though to keep control when Facebook changes the settings without your knowledge.”
He said Facebook shouldn’t require its users to constantly check their privacy settings to see what the company has changed since their last visit to the site.
“The onus should not be on Facebook users having to ‘opt-out’ of the facial recognition feature, but instead on users having to ‘opt-in’,” he said.
“Yet again, it feels like Facebook is eroding the online privacy of its users by stealth.”
Case study Some time in the not-too-distant future, a brave, if chilly, soul will send the following tweet:
“on #K2 summit. v tired. awesome view. cu @ basecamp”.
You will have the UK firm Active Web Solutions (AWS) to thank for it.
AWS has developed a Global Alerting Platform (GAP) based on Microsoft’s Azure cloud service that will allow two-way texting with a satellite phone handset.
The software will also translate a text into a tweet, if the sender is so inclined.
“We wanted to develop something that would leave a legacy,” says Rob Blackwell, R&D director at the Ipswich firm.
“Obviously, we are a business and we want to make money, but we also wanted to do something that would save lives.”
The GAP is based on an award-winning project – the Man Over Board Guardian (MOB) alerting system – that AWS completed for the Royal National Lifeboat Institution (RNLI).
Saved from the waves
This is a satellite tracking system that automatically sends an alert to the search and rescue services if a boat capsizes or if someone falls overboard.
It has already been credited with helping to save nine lives.
GAP takes things a stage further, allowing users to send and receive texts from a suitable handset anywhere on Earth. It can also send an automatic alert if the holder fails to check in at regular intervals.
As well as enabling early adopters to send tweets from absolutely anywhere, this has a more serious purpose.
Blackwell sees the system being used by organisers of trekking expedition, in the military, at sea – anywhere someone might need to send a message to the emergency services.
“What makes it different is that it is a two-way messaging system.
Emergency workers will be able to establish the nature of an emergency before responding.
No helicopters need to be dispatched to climbers who have run out of beer.”
Work with Azure, Microsoft’s platform-as-a-service development model, began three years ago.
Microsoft was so impressed with the RNLI MOB Guardian project that it invited AWS staff out to its Redmond HQ to give them an advance view of the cloud platform.
Emergency measures
In 2008, Blackwell says, AWS knew the RNLI application had tremendous potential but the firm couldn’t muster the enormous capital investment such a big satellite communications system would need.
Doing it in the cloud allowed the company to explore the possibilities fully.
“AWS would simply not have had the resources to build something as ambitious as a global platform without the cloud,” Blackwell says.
Azure is not just about new applications and services. Although that was the idea at first, AWS found that one of the cloud platform’s unforeseen benefits is that it allows a gradual migration.
And that means a need for tools and software that bridge the gap between the legacy apps and the stuff in the cloud.
AWS develops these for Temenos, the banking software company, for its T24-Services software.
In February 2011 Temenos announced that its T24 service was to migrate to an Azure-hosted cloud.
AWS provides the software that links the legacy software to the cloud apps.
Power to the students
“We’ve been hugely busy providing those development and consultancy services to clients,” Blackwell adds.
Medical and pharmaceutical research is another fruitful area for Azure, according to Blackwell.
A lot of grant money goes on computing power, and with storage in the cloud so cheap – currently of the order of 15 cents per GB per month on Azure – the ability to bring it on as and when it is needed means researchers can do more real science with their resources.
Blackwell also spends time working with computer science students at the University of Essex, who now have a global platform for their projects.
“It is a huge opportunity, not just for students, but for start-ups and individuals to try out ideas and develop applications for a global audience,” he says.
Apple’s iOS 5 mobile operating system will include support for WebGL, the emerging standard building hardware-accelerated 3D graphics with JavaScript.
But WebGL will only be available to developers building iPhone and iPad advertisements via the company’s iAd platform.
Apple man Chris Marrin recently revealed this news on the public WebGL mailing list.
“WebGL will not be publicly available in iOS 5,” he said.
“It will only be available to iAd developers.”
WebGL 1.0 was officially released in March, providing a standard means of mapping JavaScript to the existing OpenGL graphics interface.
Originally developed at Mozilla, WebGL defines a JavaScript binding to OpenGL ES 2.0.
To use it, you need not only a browser engine that supports the spec, but also a device with OpenGL ES 2.0 graphics hardware and the appropriate drivers.
The iPhone and iPad include OpenGL hardware.
On the desktop, WebGL is supported by the stable version of Google’s Chrome browser, Mozilla’s Firefox, Opera, and the nightly builds of WebKit, which serves as the basis for Apple’s Safari browser.
It’s unclear why Apple is limiting WebGL to advertisements on iOS 5. But the company has a habit of rolling out technologies in bits and pieces on the platform.
With the last major release of iOS, for instance, Apple included a new JavaScript engine with its Safari browser, but this was not available from the Safari engine used by local iOS applications. Developers using iAds, of course, are a more contained group than the sea of developers building web applications.
Presumably, Apple is testing the technology with a small numbers of devs, before rolling it out to a larger audience.
But iAds is at least an amusing choice.
Intel Labs is working to automate the tedious and error-prone process of writing device drivers and porting them to different operating systems.
Explaining the need for a tool that could synthesize device drivers, Intel Labs software engineer Arun Raghunath Says:
“A bunch of studies have shown that the prime cause of crashes in operating systems are device drivers. They’re notoriously hard to get right.”
Raghunath discussed the challenges of writing device drivers at the company’s Research@Intel 2011 event at Mountain View, California’s Computer History Museum this Tuesday, and explained what Intel Labs is helping to do to automate the process.
“The task of writing a driver is basically translating OS commands into internal device operations,” he said.
“What this means is one programmer needs to be an expert in both OS internals as well as know a lot about the device details.”
And that’s not the only problem.
“Second thing is, they are manually interpreting these documents – there’s scope for misinterpretation there,” he added.
“And that, we believe, is the prime cause for many of the bugs in drivers today.”
The “we” to which Raghunath refers is the working group in which Intel Labs is participating, with the Australian information and communication technologies research center NICTA’s Trustworthy Embedded Systems division (ERTOS), whose device-driver synthesis project is known as Termite.
Funding has come in part from a Google Research Award.
According to Raghunath, one key to device-driver synthesis is having a sufficient set of specifications for both the device and the OS of the platform connected to the device.
“The goal of this work,” he says, “is eventually to have a tool chain that will work from formal specifications and automatically generate driver code that you can directly use.”
Those specifications are provided by the device and OS manufacturers, and aren’t a separate synthesis-specific set of standards.
“We will reuse the languages that are already being used by hardware developers for their high-level device models,” he says.
“We want to leverage that.We don’t want to create a new standard – I think that’s a non-starter.”
Raghunath’s research is based on what at first blush might seem an odd choice for algorithm development: game theory.
“Our current research direction is that we’re trying to apply game theory to [bridge] this gap between OS commands to device operations.
That’s what a driver involves: translating those OS commands to internal device operations.
So we are trying to come up with algorithms to span that gap.”
Games driver synthesizers play
When asked why his research was employing game theory, Raghunath explained:
“You can view this as a game-play situation where, basically, the driver is one of the players in the game, and the environment – which is the OS and the device and whatever else happens there – is the other player.”
Raghunath’s tool sets the game in motion.
“So when the driver makes one move, the environment is trying to push the state of the device in another direction. And so the winning strategy for you is to move in the state space without entering into any state wherein you’d be stuck forever.”
As the game proceeds, the tool logs its winning moves and creates the driver from what it learns.
But it’s not as easy as it may at first seem.
“The reason this is difficult is that you’re dealing with a complicated state machine and you’re dealing with incomplete information,” Raghunath explains.
“As far as the driver is concerned, it can – for the most part – access visible registers, but not really look at all of the internal device state space.
So how do you deal with this?” he asks
“How do you come up with the winning strategy in such a scenario? So what we found is that there is existing theory in the game-play situation which we could leverage.”
The beauty part of this game-theory model is that the device-driver synthesis algorithm is fully independent of both the OS and the device that it’s negotiating with.
The device-driver synthesis algorithm would play the same game with the same basic rules, just with different “opponents” and different results.
Raghunath points to this device and OS agnosticism as a big win for his model.
“The other nice point of this, if you think of the other big bottleneck in driver development, it’s porting to different operating systems,” he says.
“So if you have one device spec for, say, a printer.
The nice thing is that once you have a device spec, say that you want to port your driver to BSD or Windows, you just get the corresponding OS spec, run it through the tools, and voilà, you have your driver for that.”
That all sounds lovely, but when asked just how detailed the specs needed to be and how available they are, Raghunath said: “Good point.
We do need at least all the externally visible interfaces of the device.
What we do need in addition is the device behavior in response to a given command that it exposes.”
Some cooperation between device manufacturers and platform developers will be required – or, at minimum, helpful.
“I think the way we see this being used is – the hardware manufacturer, when they come up with their device, they also emit a spec, they give you a device spec with that, which they can give to platform companies or the OEMs who build the platforms into which these devices will go,” he says.
Trade secrects kept secret
Raghunath anticipated the next obvious question:
whether device manufacturers would fear that detailed specs would compromise thier intellectual property.
“You can use a tool like this to essentially churn out the drivers for those devices without actually giving away intellectual property, that’s what you’re asking, right?” he guessed before being directly asked.
“Obviously the hardware vendor doesn’t want to open up their IP to the whole world and give it away,” he said.
“But we believe that the level of detail that we need is high-level enough that, without giving their IP, just the high-level model – I think in typical hardware-manufacturer parlance – the high-level model is what we care about, and that’s what we would work with.”
But even with that high-level model, Raghunath said,
“we do need to know some amount of details. What we do need to know is the theory of operations, what is currently specified in the device spec you get today is – say, for a NIC – is ‘okay, send out a packet.’ In order to send out a packet, the manual says you need to go right to this register, the set this up, set this up, and then go twiddle this bit and the packet will go out.
What we need is at least that level of information.”
But the device-driver synthesis tool can help.
“What we need is a little more detail than that,” he said, “because no one is going to tell you the theory of operation here – the tool has to figure out the theory of operation, basically, by looking at the formal device spec.
To answer your question, we do need a little more detail, but I believe we don’t need all the IP.
So therefore we do believe this is viable going forward.”
But don’t fire your device-driver coders just yet.
Raghunath told us that the group has “lots of technical issues still to figure out. What we have now is actually kind of initial signs of life that we can acually build something.
He also said that even if his first successfully automatically generated device drivers aren’t well-optimized, they’d still be a value.
“We actually also think that even if we don’t get to the most optimized driver, even if we can churn out a functionally working driver, that’s a big win, at least at the platform-validation level.”
Even a clunky driver wuold save time and effort.
“The time that it takes for you to actually just come up with a functional driver that you can then use to validate the rest of your platform,” he said, “we can just cut that entire time down to zero – well, or a few minutes.”
When asked when his tool wil be able to handle performance optimization, Raghunath chuckled. “We are far from that yet, “he said, but added: “We do believe that we can get pretty close.”
Velocity Mozilla is exploring ways of building a multi-threaded browser DOM, so that a single web page can be rendered using multiple processor cores.
“We think it’s possible,” Mozilla open source evangelist Chris Blizzard said on Thursday at the O’Reilly Velocity conference in Santa Clara, California.
“This is an active area of research, and we invite anyone to join us.”
Blizzard said that the project is very much in the early stages, but it involves Rust, a new low-level programming language built at Mozilla.
Mozilla man Graydon Hoare began Rust as a side project in 2006, but he’s now working on it full-time, according to Blizzard.
The language is built from the ground up for concurrency and safety.
“It’s a C++-like languages designed to let you build in parallelism and security,” Blizzard said.
Today’s browsers offer parallelism in other areas. Separate tabs can be run on multiple cores, though they do share some processes.
Plug-ins are now run as separate processes.
And things like http transactions and video and audio decoding are multi-threaded.
WebGL provides parallelism via GPU hardware acceleration.
And with a browser-like mobile Firefox, Blizzard said, Mozilla uses separate processes for the browser chrome and the content.
But the DOM (Document Object Model) interface used to render things like HTML and JavaScript is still single-threaded.
“The DOM and the way we do layout and the expectations and promises for the way the internal APIs behave are all single-threaded,” Blizzard said.
“It’s very difficult to make the DOM multi-core.”
With more and more applications moving to the browser, it only makes sense to break up the DOM’s tasks onto multiple cores.
This applies to both desktop and mobile devices, which are beginning to see multi-core chips.
In essence, Mozilla is working to rebuild the DOM with Rust.
“The idea is to take chunks of the DOM, take chunks of the rendering, and break them into their own tasks and actually be able to take advantage of multi-core machines in a single web page,” Blizzard said.
But Blizzard stresses that Mozilla has not deployed any code and has no real schedule for the project.
“It’s basically research at this point,” he said.
