Live data from Hacker News

OpenDrop: An Open Source AirDrop Implementation

github.com

181–190 of 231 posts

Re: OpenDrop: An Open Source AirDrop Implementation

#181
post #84
post #81

It is 2019, and it is quite surprising - and disappointing - that we STILL haven't universally solved the means to easily, securely, and (yes, I'll use this term again) universally share files. I wish we could share files in a peer-to-peer fashion securely without hindrance of mobile platform, nor blockage of network MiTM, etc.

What do you expected from a company who even cant made a phone with simple bluetooth file sharing

Bluetooth file sharing works fine on just about every phone I've used. Bluetooth just isn't built for high-bandwidth applications like this, meaning while it's fine for a photograph, you will have issues with larger transfers. That's not a flaw in the implementation, bluetooth just isn't built for high transfer speeds. It is built to transfer enough data and operate at low power, not to be just another wireless NIC.

Re: OpenDrop: An Open Source AirDrop Implementation

#182

Could this technology be used to create a "shadow" internet/network/messaging service where devices connect and communicate directly with each other. This way governments can't just block internet access or services during demonstrations.

For what it’s worth, I have been able to get the Yggdrasil Network ( https://yggdrasil-network.github.io ) to peer over AWDL, allowing nearby Macs to mesh without even being connected to the same Wi-Fi network, or any network at all. It’s not perfect - there are trade offs, like how the wireless performance is reduced somewhat when AWDL is active due to channel hopping and how AWDL expects a single node to play the r…

Any chance you could throw together a quick blog post on this? Or maybe a quick gist; doesn't have to be polished.

Re: OpenDrop: An Open Source AirDrop Implementation

#183
post #167

Earlier quoted context omitted.

The “many eyes” hypothesis is routinely debunked when severe security bugs are found in things like the Linux kernel that have been there for years. The same is true for standards that end up being fundamentally broken at later dates. In the end software and hardware is so overly complicated that we cannot currently build secure systems.

I would like to read more about this many eyes hypothesis (and its falsification). Could you please share some links for the same?

https://en.m.wikipedia.org/wiki/Linus's_Law This is the term notable hacker Eric S. Raymond (esr) popularized in his seminal work, The Cathedral and the Bazaar. Read it if you care at all about software engineering processes.

I don’t, so I didn’t.

Re: OpenDrop: An Open Source AirDrop Implementation

#184

Earlier quoted context omitted.

Enable what? Modern MacOS/iOS discourage you from disabiling Wi-Fi/Bluetooth anyway.

> Modern MacOS[...] discourage you from disabiling Wi-Fi/Bluetooth anyway. How do you figure? I've never seen any discouragement from it.

If you use the controls that slide down from the top of the screen (I'm at a loss as to what Apple calls it) and "disable" Wifi it simply disconnects from the associated AP and won't reassociate. It will turn itself back on at 7 AM tomorrow morning.

"Disabling" Bluetooth is similar, it will disconnect from paired devices, but BTLE is still available.

You have to use airplane mode, or go in to the Settings app to fully disable it. If that isn't discouragement, I don't know what is.

Re: OpenDrop: An Open Source AirDrop Implementation

#185

Would it also be possible to share contacts and links to sites? Thinking of a new reception desk feature (lots of apple customers)

I believe AirDrop defaults to "Contacts Only" so you'd need to have every customer add your reception phone number.

Re: OpenDrop: An Open Source AirDrop Implementation

#186
post #142

God, I wish people would stop using Python for these sorts of things. It is an okay language, but after tracking down why it doesn't build and considering messing around in my system and making either installing older versions of libraries or messing around with symlinks I stopped and asked myself "really? I want to spend my time fixing this?" and just deleted the entire clone of the git repos. Python is a nice langu…

I honestly haven't run into this issue in a long time. `pip install --user` is one of your friends. Just using the official python:3 docker container is another. If you really want, you can even go back to virtualenvs. npm was also really bad about nothing building or working a few years back. It's improved, and there are alternatives like yarn. Rust/Cargo has this issue as well (whenever I attempted to pick up some…

> What language do you recommend for this type of application and why?

This is the #1 reason why .NET Core gets so much of my mindshare these days. If I write something and put it out there, it will Just Work (TM) 99.99999% of the time. As soon as the user runs `dotnet build` or `dotnet run`, it'll automatically go grab the exact right versions of packages from NuGet and set everything up locally. The only time anything tricky ever happens is if some third-party library doesn't ship a native library dep for each platform; that's rare, but does occasionally happen.

Re: OpenDrop: An Open Source AirDrop Implementation

#187
post #81

It is 2019, and it is quite surprising - and disappointing - that we STILL haven't universally solved the means to easily, securely, and (yes, I'll use this term again) universally share files. I wish we could share files in a peer-to-peer fashion securely without hindrance of mobile platform, nor blockage of network MiTM, etc.

Personally I've been using Nitroshare for years in my home network and it works like a charm (between Windows, Linux, and macOS). Android is also supported, but not iOS (I saw someone created an iOS app, but I doubt it works still).

Re: OpenDrop: An Open Source AirDrop Implementation

#188

Earlier quoted context omitted.

FOSS may have downsides, for instance it's free, but doesn't have iTunes built in. I consider both of these advantages, but some users don't. I consider the benefits of open source far exceeds the perceived benefits of Apple's Ecosystem. Maybe as developers it's important to teach our Apple Peers the problems they perpetuate by paying for walled gardens.

What about your apple peer developers, who have made a deliberate and conscious choice to use Apple devices in their day to day life, and stable open source solutions in production / deployment environments? Some of us used to live in the FOSS garden, and decided to trade extra money in exchange for receiving a lot of time back and a shiny finish. Everyones values vary.

I don't think your premise that you are saving time is correct.

Apple advertises similar to Luxury car buyers to make you believe you are getting a high quality product. But it's going to be really hard to prove things are quicker.

Re: OpenDrop: An Open Source AirDrop Implementation

#189

Earlier quoted context omitted.

The “many eyes” hypothesis is routinely debunked when severe security bugs are found in things like the Linux kernel that have been there for years. The same is true for standards that end up being fundamentally broken at later dates. In the end software and hardware is so overly complicated that we cannot currently build secure systems.

Debunked is a loaded term. It's a tradeoff. The point is not MANY eyes, it's ANY eyes. Proprietary software has NO public eyes on it, zero, and the vendor must (1) report to you promptly when there's a new vulnerability, (2) produce a fix for it. Most vendors do neither until forced. How many undisclosed vulns does your vendor have? You'll never know. Of course FLOSS has bugs, it's software, and ALL software has bugs…

> Proprietary software has NO public eyes on it, zero

If that were true, security flaws would never be found in proprietary software by outsiders. And they are, so it's not true. Eyes have less visibility into the codebase, but people are looking and do find flaws.

> How many undisclosed vulns does your vendor have? You'll never know.

How many undisclosed vulns does RedHat, Canonical, or Mozilla have in their FLOSS software? You'll never know.

> Of course FLOSS has bugs, it's software, and ALL software has bugs.

Then "many eyes makes bugs shallow" is at least partly debunked and your "ANY eyes make bugs shallow" is debunked completely - otherwise the original developers would see every bug, in FLOSS and proprietary software.

> In the FLOSS case you know what everyone else knows

There may be bugs which nobody knows about. The claim "many eyes make bugs shallow" suggests that open source software has more eyes on the code, and that having more eyes on the code is all it takes to reduce bugs. OpenSSL turned out to have very few eyes on the code, and it wouldn't be too surprising if codebases with many eyes on them had the developers focused on the bits they were developing and not looking for security flaws.

Re: OpenDrop: An Open Source AirDrop Implementation

#190

Earlier quoted context omitted.

For what it’s worth, I have been able to get the Yggdrasil Network ( https://yggdrasil-network.github.io ) to peer over AWDL, allowing nearby Macs to mesh without even being connected to the same Wi-Fi network, or any network at all. It’s not perfect - there are trade offs, like how the wireless performance is reduced somewhat when AWDL is active due to channel hopping and how AWDL expects a single node to play the r…

Any chance you could throw together a quick blog post on this? Or maybe a quick gist; doesn't have to be polished.

Sure thing - I threw this together over the last hour or so: https://yggdrasil-network.github.io/2019/08/19/awdl.html
Post reply on HN