Windows 10's Version of AirDrop Lets You Quickly Share Files Between PCs (theverge.com)
Microsoft is testing its "Near Share" feature of Windows 10 in the latest Insider build (17035) today, which will let Windows 10 PCs share documents or photos to PCs nearby via Bluetooth. The Verge reports: A new Near Share option will be available in the notification center, and the feature can be accessed through the main share function in Windows 10. Files will be shared wirelessly, and recipients will receive a notification when someone is trying to send a file. Microsoft's addition comes just a day after Google unveiled its own AirDrop-like app for Android.
I used to have my "Airdrop-like" feature decades ago, simply by clicking on "share via bluetooth", until phone manufacturers (or OS companies) decided to ban sharing stuff over bluetooth. Which is the same Apple has, with the exception that they combine bluetooth and wifi (and I guess their own API) to pretend they did something new/unique.
Computer monkeys at Google and Microsoft must be really boring if they are "implementing" airdrop. Just stop f*cking messing with the information users are allowed to share (allowed... ha... it's supposed to be my bloody phone!).
IR Link was horrible, because most laptop IR transceivers had a very narrow view. It was sort-of okay for PDAs if you held the PDA directly against the IR port, but impossible to align for a pair of laptops reliably.
Bluetooth file transfer is also pretty mature at this point. I've used it between Windows, Mac, and FreeBSD machines and with old Nokia and new Android phones (it probably works with iOS, though it didn't in the original iPhone). Pairing is a bit annoying, but once that's done it's basically drag and drop.
AirDrop is nice because it uses bluetooth to identify nearby machines and to advertise public keys, but then creates a two-device ad-hoc wireless network and transfers at high speed. WiFi direct now provides a somewhat more standard and mature mechanism for doing this.
I'm quite annoyed that Apple, Microsoft, and Google are all developing independent protocols for this though. I want an open protocol that works with all of my devices, not a mess of protocols where I can use one between my laptop and Android phone, one between my laptop and iPad, none between my iPad and Android phone, a different one between Windows devices, and so on.
I am TheRaven on Soylent News
Or may I say, a security hole waiting to be used?
Quite frankly, this strikes me as one of those things that have very limited usefulness with a wealth of exploit potential behind it. What is the scenario for the use of this feature? When you have a meeting and want to exchange documents? What company does NOT have a wireless AP in their conference rooms these days? Oh, when you have to exchange documents with someone outside your company who you can't let on your WiFi for security reasons? Use an USB Stick. If you're security conscious enough to not let a stranger onto your WiFi that is administered and controlled by your IT staff, you should definitely be security conscious to NOT let some marketing or management computer illiterate make decisions about sharing stuff on his laptop, the same laptop that probably contains the marketing strategy or the financial data for the next quarter, most likely in the same folder as the document that should be handed over.
So what sensible application is there for this security-hole-in-the-making?
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
I congratulate Microsoft for this great achievement, they finally implemented a feature which Ericsson R520 had 17 years ago.
Let's use the most insecure protocol ever developed to send potentially personal information into the ether for everyone to grab.
What could possibly go wrong?
I'd prefer a system for portable devices that required physical contact.
If there's so much data to move you can't hold the devices against each other reliably for long enough... you can probably find the time to sit them on a table.
I'll second this; Bluetooth proved useful in scraping everything off a Nokia 6310 onto a laptop. Quaint old phones without USB or anything.
That is exactly why it was good. Line of sight in a narrow angle is secure. Bluetooth is insecure by design.
An open protocol could exist between PC and Android. Apple would never want to play ball as file transfer would be at odds with the Golden Cage concept.. or was it called Walled Garden? I do not recall. ;)
I think of it as the Golden Shower Cubicle concept.
I'll see your Constitution and raise you a Queen.
Bluetooth file transfer is also pretty mature at this point. I've used it between Windows, Mac, and FreeBSD machines and with old Nokia and new Android phones (it probably works with iOS, though it didn't in the original iPhone). Pairing is a bit annoying, but once that's done it's basically drag and drop.
...
I'm quite annoyed that Apple, Microsoft, and Google are all developing independent protocols for this though. I want an open protocol that works with all of my devices, not a mess of protocols where I can use one between my laptop and Android phone, one between my laptop and iPad, none between my iPad and Android phone, a different one between Windows devices, and so on.
Not sure why we need a new protocol when we've got OBEX.
https://en.wikipedia.org/wiki/...
Like you say it's supported by literally everything.
My Galaxy S5, Windows machine and Mac all support it. Even old feature phones did - in fact that's where it was invented.
As far as pairing goes it's not too bad now. With NFC you can tap to pair, though I've never owned two devices that support it. Even without it you can fiddle around in the GUI once to pair and then click OK on both devices - the PINs are synched automatically. It's about the minimum security that is viable to stop drive by downloads.
I.e this is a solved problem and there's no need for a new protocol. If it is more convenient it will necessarily be less secure. And a vendor specific protocol is obviously not going to be much use with a heterogeneous bunch of devices.
Also if you want more speed Android, Mac, Windows and Linux/BSD all support SMB networking over Wifi. So for a large file you can just copy to a mutually visible network share.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
I don't like Apple's push for proprietary interfacrs either but to be fair to them they support OBEX over Bluetooth already, at least for OS-X.
https://en.wikipedia.org/wiki/...
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
IR Link was horrible, because most laptop IR transceivers had a very narrow view. It was sort-of okay for PDAs if you held the PDA directly against the IR port, but impossible to align for a pair of laptops reliably.
On the other hand, most of the PDA and phone I've had back then all worked nicely. Seems engineering spent more time testing if the IR solution was optimal, compared to laptop where IR was an additionnal check on the feature list.
Bluetooth file transfer is also pretty mature at this point. I've used it between Windows, Mac, and FreeBSD machines and with old Nokia and new Android phones (it probably works with iOS, though it didn't in the original iPhone).
Nope. Bluetooth file sending (OBEX) doesn't work on iOS anymore. Apple has removed the feature and replaced it with a proprietary Bluetooth-enabled version of AirDrop.
AirDrop is nice because it uses bluetooth to identify nearby machines and to advertise public keys, but then creates a two-device ad-hoc wireless network and transfers at high speed.
Which is stupid and redundant given that most recent bluetooth standards (Bluetooth 3.0 + HS and more recent) can do it themselves ("Alternative MAC/PHY" - BT 3.0 do the hand shake on classic bluetooth, but then can re-use their wifi's 800.11 MAC/PHY to do high-speed transfers).
Which means that even ancient obsolete Apple devices like the iPhone 4S could do it.
Using OBEX on any more recent BT device achieves the exact same thing, and is a standard thus not needing any vendor proprietary incompatible extensions.
The only situation where the AirDrop kludge seems to make sense is in the home-built no-name beige-boxes, where Bluetooth and WiFi are handled by completely different extension modules (e.g.: a USB Bluetooth dongle and a PCIe Wifi card) and thus BT can't see/access the WiFi MAC/PHY.
(Happens also on a few older laptops my old Dell Latitude uses separate module for BT and Wifi. But lots of modern laptops tend to use combined Wifi + Bluetooth modules. It's not only for space saving, it also makes "Alternate MAC/PHY" work).
I'm quite annoyed that Apple, Microsoft, and Google are all developing independent protocols for this though. I want an open protocol that works with all of my devices, not a mess of protocols where I can use one between my laptop and Android phone, one between my laptop and iPad, none between my iPad and Android phone, a different one between Windows devices, and so on.
...and you see where all this is going :
There is one such shared protocol, and it's called DropBox. Or Google Drive. Or iCloud. etc.
Basically, the manufacturer have low incentive in developing (or keeping, in the case of bluetooth OBEX) cross platform standard - because they let the user swap files for free. This eats into the profits of any cloud-storage solution. (DropBox "Pro" accounts, etc.)
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Wow, a whole new target for hacking. Bluetooth range is pretty variable - someone sitting in a conference room or a waiting room has a good chance of contacting a computer on the other side of the wall. Many users will be completely unaware that this feature even exists.
How long until the first hack?
Enjoy life! This is not a dress rehearsal.
OBEX started off on serial and IRDA and moved to Bluetooth. You could presumably run it over WiFi - e.g. encapsulate the packets into TCP/IP or UDP. I'm guessing done right - with the right windows size basically - you should be able to get close to the native speed of the WiFi connection.
There's a standard for OBEX over TCP/IP
https://books.google.com/books...
https://i.imgur.com/WhzUaDB.pn...
The problem would be how you'd balance convenience and security. With Bluetooth you need to pair. With Wifi you need to know the password for the network.
So what happens with OBEX over TCP/IP? Both devices would need to be on the same subnet, unless you had some sort of evil NAT avoiding technique to punch through to an external server. But is that what you really want? I.e. allowing anyone to read and write files on the device? OBEX doesn't have any security built in because it was designed for IRDA or Bluetooth where the security comes from proximity or pairing and usually a "This device is trying to connect? Allow once, allow always, deny" dialog. Run it over TCP/IP and you've got an unsecured way to read and write files and that seems dangerous. Even the dialog would be easy to fake unless you do SSL certificate verification which is fine for webservers but sucks for devices on the the same subnet.
Honestly I think I'll stick to SMB shares. The speed of those is limited by the storage device, not the network. You can saturate a Wifi connection with a cheap NAS. You get Wifi security, such as it is these days and you can password protect the shares. Obviously it's not ideal, but it's better than OBEX where you get no security with a naive OBEX over TCP/IP connection.
SFTP isn't too bad either. I like it because Macs listen by default and you have a certain amount of trust in the device identity because of SSH fingerprints. Also AndFTP has a nice Sync feature so you can sync a directory on an Android device with a Mac.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
And pay $PPLE a shit ton of money, or risk getting sued?
No risk if you do the reverse engineering of the protocol in the EU - which specifically allowed you to do that. See the UK Act: The Copyright (Computer Programs) Regulations 1992, read 50B (2)(a)