They said this hack was impossible(venturebeat.com)
venturebeat.com
They said this hack was impossible
http://venturebeat.com/2013/11/19/apple-android-windows-fasetto-offline/
56 comments
It's still cool for android and windows mobile though. It implies that the transfer speed is much faster than the existing options on those platforms.
"1GB in 10 seconds" is 819Mbps. This is snake oil territory. Even if they put the pedal to the metal on every single radio in the device simultaneously you can't push data that fast.
The numbers I see in the article are 100mb in under a minute. Where did you get your quote?
That's from their Kickstarter page.
"...Even when they're offline!"
I was expecting some arcane optical-modem procedure where you point the receiving phone's camera at the sender's screen, which flashes a series of glyphs or something like a high-bandwidth QR code. That would've been cool. Instead it turns out that "even when they're offline" just means "we were lying about that part." Oh well.
I was expecting some arcane optical-modem procedure where you point the receiving phone's camera at the sender's screen, which flashes a series of glyphs or something like a high-bandwidth QR code. That would've been cool. Instead it turns out that "even when they're offline" just means "we were lying about that part." Oh well.
Heh. Well "offline" probably means you don't see the little WiFi bars on the status bar. You can put a Wifi chip in what is effectively promiscuous mode and have it talk to an ad-hoc network (which appears to be what they are doing) that or a bluetooth PAN connection.
Bidirectional video QR would awesome. 320x480 x 4 gray levels x 10 fps = 768Kps. You could at least transfer pictures in only a few seconds.
Huh, it was pretty obvious to me that it meant 'not connected to the internet'.
Hmm. "Offline" is a bit more nebulous with a cellphone, since you can reasonably expect it to send and receive data (calls, text messages, GPS) even when there's no active Internet connection. From the article's breathless language, it really sounded like they were trying to say "not sending or receiving any radio signals," only then it turned out that they weren't.
I tend to think this is an impossible hack, or at least the article is grossly exaggerating things. From the sound of it, they somehow managed to get directly into the wifi and bluetooth chipsets, hijacked them to use [something?] to magically transfer data while they are disabled somehow below the TCP/IP level, within a sandbox...
I mean, assuming they actually did manage this, it wouldn't be portable either. It sounds like they'd have to implement their own driver, which would mean hardware dependence.. and then theirs the fact that they are apparently breaking out of the sandbox and getting direct hardware access, a major exploit..
I call BS
edit: Note, I know that wifi is capable of P2P/ad-hoc connections, and it's what bluetooth uses exclusively... The article seems to say that this app doesn't use that though and has these things disabled
I mean, assuming they actually did manage this, it wouldn't be portable either. It sounds like they'd have to implement their own driver, which would mean hardware dependence.. and then theirs the fact that they are apparently breaking out of the sandbox and getting direct hardware access, a major exploit..
I call BS
edit: Note, I know that wifi is capable of P2P/ad-hoc connections, and it's what bluetooth uses exclusively... The article seems to say that this app doesn't use that though and has these things disabled
The article is unclear about what exactly needs to be enabled in order for the app to work, but I don't think they are saying they can hijack wifi even when it's disabled. An important quote from the article on this note is
"So while PDQ doesn’t require existing connections, it uses the existing wireless chips to send data across short distances, which could be useful during power outages or natural disasters. That means you can’t have your iPhone in airplane mode while using PDQ, for example, because then it wouldn’t be able to tap into its wireless chips."
"So while PDQ doesn’t require existing connections, it uses the existing wireless chips to send data across short distances, which could be useful during power outages or natural disasters. That means you can’t have your iPhone in airplane mode while using PDQ, for example, because then it wouldn’t be able to tap into its wireless chips."
It's a stretch, but I think the implication is that even if your wifi router is out of power, two powered on phones will be able to communicate, even with "wifi" disabled as long as the wifi or bluetooth radio can get power.
Transfers even without power, as in wireless network routers/towers don't have power, but phones still do.
Transfers even without power, as in wireless network routers/towers don't have power, but phones still do.
The implication in the article is that it turns on the Bluetooth or WiFi chip and sends the data. The radios are off to begin with, but the software turns them on.
Quote: “And then we’ve built a whole new layer on top of that that is standardized in our software — so an iPhone and a Windows Phone are going to know how to discover each other and communicate, because they’re using our standardized layer, as opposed to the incompatible standards that are out there today.”
Yes -- a whole new incompatible layer.
I cannot tell you how many times I've heard this exact pitch during my long career in this business. "Our method breaks through the morass of incompatible, adversarial protocols" ... by creating yet another incompatible, adversarial protocol that refuses to work with any existing ones.
The only difference between this and Microsoft's classic "Embrace, Extend and Engulf" strategy is that small companies can only create a new niche protocol, hopefully soon to be forgotten.
Zeroconf was more than good enough. UpNp was more than good enough. And so forth. But no one is willing to adopt anyone else's universal, flexible, foolproof communications protocol.
Yes -- a whole new incompatible layer.
I cannot tell you how many times I've heard this exact pitch during my long career in this business. "Our method breaks through the morass of incompatible, adversarial protocols" ... by creating yet another incompatible, adversarial protocol that refuses to work with any existing ones.
The only difference between this and Microsoft's classic "Embrace, Extend and Engulf" strategy is that small companies can only create a new niche protocol, hopefully soon to be forgotten.
Zeroconf was more than good enough. UpNp was more than good enough. And so forth. But no one is willing to adopt anyone else's universal, flexible, foolproof communications protocol.
I would like to know who told them that it's physically impossible for software to turn a radio on, look for other radios nearby, pair, and then send data.
Because that's basically what radios (and the software that controls them) are designed to do.
Because that's basically what radios (and the software that controls them) are designed to do.
It impossible for an app to do this, because sandboxing doesn't allow it.
Hence the debate about whether or not Apple or Microsoft will allow this into their app stores. Interestingly enough, this uncertainty is not mentioned in the Risks section of their Kickstarter page. They're promising software that could very likely never be allowed to be used by the majority of the people funding it.
I know that Android at least has a specific API and permission for direct peer-to-peer WiFi connections with other devices.
I would like to know how they break out of sandbox and actually access physical radio on iOS without jailbreak. Because you know, it is not like Apple would like to patch that asap.
You should change the title - the content is interesting enough that you don't need the mystery, and many people who would otherwise be interested probably won't click.
Cool stuff though!
Cool stuff though!
No, I think the BS title is the perfect lead-in for this sort of BS article, which provides no details and makes completely ludicrous claims e.g. being able to directly talk to cell radio hardware from an iPhone app sandbox.
It was made pretty clear that the app is using the WiFi and bluetooth radios, not the cell radio.
Still very improbable that this app has direct, hardware-level access to these chips. Or--if it does--that the sandboxes won't be patched to fix the hole this app is using.
You may as well invest in a Kickstarter for a free energy machine.
You may as well invest in a Kickstarter for a free energy machine.
Physically on chip, they are one in the same, especially since they share antennas.
There's no way apple will let this through. A lightly secured connection protocol that can talk to your device disk sounds like a security nightmare. A nice 0-day exploit and a stroll through a downtown BART station sounds like a blast.
There's no way apple will let this through. A lightly secured connection protocol that can talk to your device disk sounds like a security nightmare. A nice 0-day exploit and a stroll through a downtown BART station sounds like a blast.
"That means you can’t have your iPhone in airplane mode while using PDQ, for example, because then it wouldn’t be able to tap into its wireless chips."
The only radio that's disabled in Airplane Mode is the cell radio. WiFi and Bluetooth still work if you turn them back on (Airplane Mode turns them off, but does not disable them).
Maybe they didn't actually mean that or understand what they were saying. But that's what I'm saying: BS article.
And it's not like it really matters. You can hardly talk directly to the WiFi or Bluetooth chips from an iOS app sandbox either.
The only radio that's disabled in Airplane Mode is the cell radio. WiFi and Bluetooth still work if you turn them back on (Airplane Mode turns them off, but does not disable them).
Maybe they didn't actually mean that or understand what they were saying. But that's what I'm saying: BS article.
And it's not like it really matters. You can hardly talk directly to the WiFi or Bluetooth chips from an iOS app sandbox either.
>The end goal for Fasetto, said Christmas, is taking back control of our technology.
So this will be FOSS, right?
So this will be FOSS, right?
It sounds like they took the layer written by the big bad boys and added in...their own...layer.
Errr...
Errr...
I don't expect you to be able to do point to point GSM comms. That's "reasonable".
Further, while it disappoints me that you can't easily do point to point wifi between, for instance, iDevice and winphone, I'm not really surprised.
But I do not understand the bluetooth part. Granted, I have a very, very dumb phone so I'm not doing things like this at all, but I assumed that simple file transfer via bluetooth would work just fine between, say, iDevice and Android ... it's really troubling to learn that's crippleware.
I mean, that's the whole point of bluetooth.
Further, while it disappoints me that you can't easily do point to point wifi between, for instance, iDevice and winphone, I'm not really surprised.
But I do not understand the bluetooth part. Granted, I have a very, very dumb phone so I'm not doing things like this at all, but I assumed that simple file transfer via bluetooth would work just fine between, say, iDevice and Android ... it's really troubling to learn that's crippleware.
I mean, that's the whole point of bluetooth.
If one of your phones has tethering enabled, you can turn on the hotspot and have the other phone connect to it. This should work even if there's no cell phone reception. Is that easy?
> “We’ve gone right down to the hardware level and rewritten the transport layer, so we’re talking directly to the hardware chips on the device,” said Luke Malpass, Fasetto’s lead (and currently only) developer. “And then we’ve built a whole new layer on top of that that is standardized in our software — so an iPhone and a Windows Phone are going to know how to discover each other and communicate, because they’re using our standardized layer, as opposed to the incompatible standards that are out there today.”
At first it sounds like he's claiming that they created their own drivers for the wireless chips of seemingly every phone. Which is pretty much impossible (for them).
What's probably happening is they're enabling ad-hoc mode on the wifi chips, and enable bluetooth transport between any two devices nearby each other. Then their app deals with the addressing and routing of messages using some proprietary tunneling, with probably some kind of virtual network interface that talks to their app so they can communicate on multiple networks at once.
It's a neat idea that makes it easier to do networking between devices. But the title ("They said this hack was impossible") is incorrect. Ad-hoc wifi networks and bluetooth network transport works just fine with existing devices and no other software.
As usual, the idea with this piece and their website is to exaggerate as much as possible to drum up funding. If people figured out how boring this really is they might not get enough press.
At first it sounds like he's claiming that they created their own drivers for the wireless chips of seemingly every phone. Which is pretty much impossible (for them).
What's probably happening is they're enabling ad-hoc mode on the wifi chips, and enable bluetooth transport between any two devices nearby each other. Then their app deals with the addressing and routing of messages using some proprietary tunneling, with probably some kind of virtual network interface that talks to their app so they can communicate on multiple networks at once.
It's a neat idea that makes it easier to do networking between devices. But the title ("They said this hack was impossible") is incorrect. Ad-hoc wifi networks and bluetooth network transport works just fine with existing devices and no other software.
As usual, the idea with this piece and their website is to exaggerate as much as possible to drum up funding. If people figured out how boring this really is they might not get enough press.
This article is misleading in its description of the technology and its use of phrases such as "...their lack of cell, Wi-Fi, Bluetooth, and NFC connections." They seem to confound lack of wide-area connections with a lack of local-area connections. It appears the authors simply have a protocol they have devised agnostic of a specific transport layer, and they are writing interfaces to every transport layer possible on the top three mobile platforms.
I highly advise anyone interested in this to instead read the information on the Kickstarter page: http://www.kickstarter.com/projects/fasetto/fasetto-sharing-...
I highly advise anyone interested in this to instead read the information on the Kickstarter page: http://www.kickstarter.com/projects/fasetto/fasetto-sharing-...
I read Fasetto as Falsetto and figured they were using high-frequency audio to transmit data between phones. An app using that shouldn't have any issue getting approved (just needs speaker/mic), but I suppose the data rate would be pretty low.
It seems that it just tries whatever the device offers. From the kickstarter:
"If Bluetooth isn’t available it can use near field, if near field isn’t available it can use WiFi Direct, if WiFi Direct isn’t available it can use hotspot, and if that isn’t available it can use root sockets (TCP, UDP or any other supported protocol, using any port)."
I'm not sure what "root sockets" means, or how UDP is going to allow you to transmit without WiFi, NFC, or Bluetoth.
It seems that it just tries whatever the device offers. From the kickstarter:
"If Bluetooth isn’t available it can use near field, if near field isn’t available it can use WiFi Direct, if WiFi Direct isn’t available it can use hotspot, and if that isn’t available it can use root sockets (TCP, UDP or any other supported protocol, using any port)."
I'm not sure what "root sockets" means, or how UDP is going to allow you to transmit without WiFi, NFC, or Bluetoth.
Has anyone written an app to transfer data through the headphone jack for P2P data sharing?
Along the lines of "I don't have network and I want to share with someone else on a different platform and don't (or can't) use bluetooth/wifi".
Narrow population, but it would be a fun project to learn about sending data over an audio medium.
Get it working well and you might even be able to send data over a set of headphones/mic, although your data throughput would likely be slow as molasses.
Along the lines of "I don't have network and I want to share with someone else on a different platform and don't (or can't) use bluetooth/wifi".
Narrow population, but it would be a fun project to learn about sending data over an audio medium.
Get it working well and you might even be able to send data over a set of headphones/mic, although your data throughput would likely be slow as molasses.
TinCan[1] does that, at least with text. There was a discussion here a few months ago about using AFSK to control external hardware that spurred me to hack together a script that allows this (output only) on iOS Safari[2] and I use it to control some Arduino projects.
[1] https://play.google.com/store/apps/details?id=com.hubski.com...
[2] http://sixteenmillimeter.github.io/Javascript-FSK-Serial-Gen...
[1] https://play.google.com/store/apps/details?id=com.hubski.com...
[2] http://sixteenmillimeter.github.io/Javascript-FSK-Serial-Gen...
I would guess root socket is a misnomer for raw socket, but it still doesn't make any sense.
I mean, will this work after Apple patches their OS so you can't breakout of the application sandbox? This is pretty cool and all but it seems to me like a bug. Something they should report to Apple (or Google/Microsoft) get some sort of reward from a bug bounty program and be on their way.
I thought the app sandbox was designed to specifically prevent app makers from accessing the hardware in unauthorized ways. (I am guessing Android and Windows phones have similar ways of controlling access to the hardware). This seems like the exact use case that should be stopped.
I thought the app sandbox was designed to specifically prevent app makers from accessing the hardware in unauthorized ways. (I am guessing Android and Windows phones have similar ways of controlling access to the hardware). This seems like the exact use case that should be stopped.
Indeed. "iPhone app I downloaded running custom drivers on my network hardware" is exactly the sort of non-evil thing the sandbox is supposed to stop.
There is simply no way what they're doing is kosher with Apple, nor should it be. For a sandboxed application to run custom drivers on my hardware defies any notion of security.
Jailbroken phones where people have acknowledged the risk of running things outside the sandbox? Sure. Great.
There is simply no way what they're doing is kosher with Apple, nor should it be. For a sandboxed application to run custom drivers on my hardware defies any notion of security.
Jailbroken phones where people have acknowledged the risk of running things outside the sandbox? Sure. Great.
I hate it when articles lack of technical details, or fail to disclose important information.
I find it interesting that their website announces that they're gonna be launching all of thei apps by January 2014, considering that their kickstarter hasn't ended, and that it's almost sure that Apple won't play along.
That said, I'm all up for a quicker way to share things with my friend's Android, so while the article is far from making me want to support this, I might give it a try once it's out.
I find it interesting that their website announces that they're gonna be launching all of thei apps by January 2014, considering that their kickstarter hasn't ended, and that it's almost sure that Apple won't play along.
That said, I'm all up for a quicker way to share things with my friend's Android, so while the article is far from making me want to support this, I might give it a try once it's out.
A lot of smart people said something that was eventually done with software was "physically" impossible? Who were these smart people exactly?
I'm curious about the security layer. It sounds like a one-time pad kind of setup. If true, does that mean the devices involved have to be synched up in a different secured environment to share the encryption codes and the protocols on how they should be used?
Eventually it will offer phone calls and text messaging? So you can call people in the immediate vicinity?
I'm curious about the security layer. It sounds like a one-time pad kind of setup. If true, does that mean the devices involved have to be synched up in a different secured environment to share the encryption codes and the protocols on how they should be used?
Eventually it will offer phone calls and text messaging? So you can call people in the immediate vicinity?
Will Apple even permit this in their appstore? Sounds like the kind of thing they would not be happy about.
This doesn't seem so impossible, if device can work as a wi-fi hotspot, instead of forwarding Internet connection, it can just send a file to other device, unlike AirDrop, which needs a router to establish communication between devices.
Or maybe I'm wrong...
When they said completely offline I was expecting all radios to be completely off.
The claim is that they are breaking out into kernel mode from the userland sandbox? Seems very implausible.
iPhones have (something very similar to) this baked-in as of iOS 7 in the form of AirDrop.
I'm pretty sure AirDrop needs either a WiFi or Cellular connection, as the article states, this needs neither.
Also, AirDrop doesn't share with Android and Windows Phones.
Also, AirDrop doesn't share with Android and Windows Phones.
> I'm pretty sure AirDrop needs either a WiFi or Cellular connection, as the article states, this needs neither.
No, AirDrop does not require wifi or cellular. It uses Bluetooth LTE to scan for nearby phones and then establishes an ad-hoc wifi connection.
You can't use it if you have wifi turned off (or airport mode turned on), but it works whether you're connected to a network or not.
> Also, AirDrop doesn't share with Android and Windows Phones.
And as of November 19 2013, this does not either.
No, AirDrop does not require wifi or cellular. It uses Bluetooth LTE to scan for nearby phones and then establishes an ad-hoc wifi connection.
You can't use it if you have wifi turned off (or airport mode turned on), but it works whether you're connected to a network or not.
> Also, AirDrop doesn't share with Android and Windows Phones.
And as of November 19 2013, this does not either.
AirDrop does do what they are describing. Airdrop uses ad hoc wifi to enable iOS devices to communicate with each other without a router or some other networking device in the middle.
But it is not cross platform, obviously.
But it is not cross platform, obviously.
Uhm, ad-hoc?
Very interesting, so are they creating an adhoc connection from the device?
who are 'they'?
You can always tell an article is going to be subpar by its use of weasel words in the title.
The author of this article, and more worryingly the developers running a Kickstarter campaign, seem to have an insufficient understanding of the technical criteria upon which Apple admits or rejects apps.