cvieira

I don’t see how using a proprietary license will help your dilema

I guess I should clarify: Predator itself is already entirely open source, offline, and self-contained. The issue here is regarding an external service that allows you to import and manage data collected by Predator. By making this external service proprietary, I would be able to host the service and regulate how it is used. By making it open-source and self-hostable, I'm giving up control over how people use it.

If you license your project under the AGPL, the code is required to be available so people can ensure that their government is not abusing the power they have lent

I'm not sure this is how that would work. The AGPL specifically guarantees users of the software the right to use it for whatever purpose they want. Assuming the government doesn't host a public instance of the software for third-party users, they are under no obligation to share the source code. As such, they could continue doing whatever they want with it with zero oversight.

The argument for a proprietary license would be that V0LT maintains control over the only public instance, meaning it could enforce the rules each agency agreed to. For example, a university wanting to do parking enforcement could be given a 7-day license plate retention limit, and have their ALPR geofenced to the perimeter of the campus. This oversight would not be possible with a free license, hence the dilemma.

Surely someone who wants to centralize ALPR information will simply use a service that already supports that feature. It seems unlikely someone trying to conduct mass surveillance would chose to modify a product specifically designed to make that difficult when there are already dozens of services that support that natively.

dont collect it all to some central database but have everyone make their own for private use.

This is how it currently works, and it's why I think Predator is a better alternative (as far as privacy goes) to traditional ALPR services. Everything Predator records is stored locally unless explicitly configured by the user to do something differently.

What use is it to regular people to track others licenceplates?

To be clear using the word "track" is a bit generous here. An individual user won't have nearly enough data to have anything close to a comprehensive location history on any given vehicle. A Predator user might be able to say "I've passed this car 3 times in the past month" but not "This person leaves for work every day at 9am".

Predator is designed primarily to make use of 'hot-lists' where only license plates in a specific list trigger alerts. For example, the US has a program called AMBER alerts, in which emergency alerts can be issued for missing children/kidnappings. These alerts often have license plates associated with them. A Predator user can add a plate from an AMBER alert to their hot-list, and then forget about it. Predator will silently scan license plates as they drive, and alert the driver if they find the vehicle. I think this is a way better alternative to government agencies covering an entire neighborhood in license plate cameras that feed everything to a centralized database.

the whole thing will likely just be taken from you by force if nothing else works

This seems unlikely to me. There are already established companies in the space who have zero issue with violating privacy (i.e. Flock ALPR and Axon). A malicious company or government entity is unlikely to willingly go after Predator, given that it goes out of its way to make mass surveillance difficult.

I suppose so, but it certainly couldn't hurt, especially if users have to be approved, and have geofenced restrictions.

I get what you're saying, but I figure someone who's prepared to do that probably wasn't someone who I was going to be able to stop from using Flock ALPR to begin with.

I guess I'll reframe the question a bit: Flock ALPR is the dominant brand in this field, and they have shown zero desire to protect individual liberty and privacy. This latest utility I've been experimenting with tries to replace the functionality of Flock ALPR with decentralized private data sources, rather than massive centralized databases (which I think is vastly better for privacy and reducing government overreach). The question is: would such a product improve privacy/freedom by eliminating the need for Flock (and competitors), or just further contribute to the problem?

That's actually something I've noticed working on this project. Some people have have never heard of dash-cams, let alone ones with ALPR capabilities. People who are uncomfortable with that idea are usually pretty shocked when I explain to them what the little cameras all over their neighborhoods are for.

It feels like a bit of an uphill battle trying to eliminate state-sponsored ALPR, so my hope is that providing a less invasive alternative might be beneficial. It's certainly a tough balance.

The cat is a bit out of the bag on that one.

Predator has been several years in the making at this point, but I've been trying to balance limiting mass surveillance while still having a product that's compelling enough for people to be willing to give up the traditional mass surveillance methods.

As far as the data import utility goes, that component is still private while I figure out how to handle it.

I think you might be over-estimating the power of Predator a bit. There are already companies dedicated entirely to high-end vehicle-based ALPR, as well as fixed road-side ALPR networks. Most of the scenarios you've listed are significantly more difficult to accomplish using Predator, since it's inherently self contained. An individual might be able to tell that they've passed a specific vehicle a few times over the past few months, but they won't be able to collect nearly enough data to "track" them.

Here's a scenario: A driver has a Predator dash-cam installed in their vehicle. One day, the local police put out a notice asking if anyone has seen a specific stolen vehicle. The driver goes home, imports the Predator data, and finds that they have records of passing that vehicle twice over the past month. They report that information to police to help with the investigation.

The concern with this is that the ability to import data makes it possible for a coordinated organization (like a police force) to install cameras in a fleet of vehicles, and manually import that data at the end of each shift. With a larger set of information, you could realistically use Predator to track the habits of individual vehicles.

You're bringing up many of the points I regularly consider working on this project. It boils down to the fact that this technology is widespread, and will continue to be widespread regardless of my actions. The catalyst for starting this project was when I learned what Flock ALPR cameras looked like, and noticed how widespread they were. I wanted to build something that could replace them without compromising privacy.

It's difficult, since there's an argument to be made for both sides. I'd argue that the existence of Predator gives an alternative to to invasive products like Flock ALPR. But at the same time, I think it'd be great to live in a world where this technology required warrants, transparency, and other oversight from the start.

Regarding the name, Predator seems to be a bit of a point of contention. As a point of clarification, Predator does way more than just ALPR. It's a fully featured dash-cam with object recognition, deep vehicle integration, and more. In nature, predators often have sharp vision and quick reflexes, which was the main motivation. It also opens up some clever branding options. For example "Predator Apex" is the commercial side of Predator, and each preassembled product is named after a predator (Scorpion, Owl, Falcon, etc.) Additionally, other brands in the automotive/law enforcement space tend to have rather sharp sounding names as well ("Cobra", "Dragon Eye", "Stalker", etc.)

Surely if I've made it this many years into the project without having a change of heart, that won't change any time soon.

That being said, I get what you're saying. Relying on human filtering seems prone to error.

85 needs to be connected to 12v, not ground.

I think you may have just solved my problem. When I've used relays in the past, pin 85 was connected to ground, since I wanted the relay to close when the trigger went high. I'm not sure why it never occurred to me that I'm essentially trying to do the opposite thing here, since the horn is triggered when the trigger wire is connected to ground.

I've never worked with individual diodes, so I'm not sure about the correct terminology, but which way would I want the diode to "face"? Do I want it to allow current to run from the 12V source, through the added relay, to the horn switch wire, or the other way around?

Additionally, would I need to add an in-line resistor? It makes me a little nervous connecting the horn switch to 12V, given that I doubt it's designed to carry a significant amount of current.

It seems like the horn wire is normally at 12V, and pressing the horn brings it down to about 0V. I figure the horn switch it just shorting that wire to ground, which in turn triggers the factory horn relay. Would a dioide in like with my trigger relay stop the add-in relay from connecting the factory horn wire to ground?