532 points | by arrdalan3 days ago
where visual representation can be recreated, similar to how LiDar does it
I’m not sure if thats more or less data to store, but it can show the depth and direction of intrusions into your space
If instead of practical and widely available technologies we are discussing scifi concepts which have no realistic prospect of materialising then why not wish for a force field impervious to trucks? Or even better, lets skip the whole middleman and wish for point to point teleportation for all cargo eliminating all dangers and externalities of trucks.
Hopefully as more people use them, there should be more chance of video footage being available from other vehicles if you're involved in a RTC and don't have one yourself. There's also the protective effect of people uploading bad driving to the police where the police are interested in road crime - hopefully providing the police with a very cheap way of having visibility in lots of places.
Or did you mean as a deterrent? Which is fair enough (although a fake camera would achieve the same)
And if someone is trespassing and about to commit a crime, you can be notified (yes even as an individual, with your own private self-hosted solutions even) immediately so that you can call police or deal with it however you want, especially if you're not home.
The traditional symmetric approach (which also has post quantum resistance) in such systems requires the camera hardware to possess the long-lived symmetric key which can be extracted after seizure. Using a ratcheting mechanism (hashing the key every t time) can help - but have no self healing and be vulnerable to recovery from persistent storage (past keys may not be securely erased).
[1] <https://en.wikipedia.org/wiki/Key_encapsulation_mechanism>
[2] <https://libsodium.gitbook.io/doc/public-key_cryptography/sea...>
https://github.com/maxlab-io/tokay-lite-pcb
or can be purchased at:
https://www.mouser.ca/ProductDetail/Maxlab/TOKAY-LITE-01?qs=...
All the closed source ones I’ve seen set the aperture/exposure based on the average exposure of the frame, so the plate comes out as a pure white rectangle.
Have it sweep through bright and dark when recording at night.
I bought cameras that use RTMP and RTSP, and sent them to my developers. From there, it is not a hard task to use WebRTC (which has end-to-end encryption) to stream somewhere. But my use case involved retaining encrypted videos (every minute and every camera would have a different key) and have a well defined protocol for decryption. To me, the issue of security is not just on one end (recording the crimes) but the other end (mass surveillance, aka who watches the watchers?)
Here is a longer write-up I did: https://community.qbix.com/t/balancing-privacy-and-accountab...
If anyone is interested in working on a startup with me and selling to homeowners and gated communities, reach out to greg at the domain qbix.com
End-to-end encryption is a pretty specific term and clearly not what is done here. Even if you use protocols designed for end-to-end encryption that does not matter if the protocols talk with an intermediary (the hub) that decrypts the traffic.
For example, if signal still used the signal protocol but decrypted the messages on their server that would not be acceptable to be called end-to-end encryption.
You can use e2e if the data-at-rest (e.g., video) file(s) are also 100% encompassing the encrypted in both the camera and the remote server, as well as the mobile app and remote server.
From the client-side, this E2E means no raw data are exposed over network nor in remote storage and that keys are required to view the raw data at either endpoints.
In today's parlance, the undefined portion of E2E is whether the local storage is encrypted as well. Some will argue on this point. Future may (and should) tighten this E2E as well.
Anyway, either way it's probably good to include something about how the traffic between the camera and the hub is completely plaintext and unencrypted and includes the password to the camera (unless I'm missing something), so even in your model it's not just the hub that is an additional point that needs to be trusted, it's also the whole network that they are on. That's probably at least a router and might include many other devices, sometimes quite untrusted.
Since some cameras support adding TLS/HTTPS it would be good to add support for that by not hardcoding http for the onvif endpoints. I think FFMPEG supports rtsp over tls out of the box.
This is key to the claim that Privastead offers superior privacy to other solutions, but it's not explained.
My NVR [1] only uses a trusted server that is intended to be in the same building as the cameras. I similarly recommend not allowing the cameras to access the Internet, as their closed-source software is typically a complete nightmare in terms of privacy and security.
My NVR's based on the assumption that you want to record continuously (as called out in the schema design doc here [1]) rather than trust event detection to be perfectly reliable. I've set up other systems in parallel that are based on a different assumption (e.g. Frigate) but have found they miss things, so this is the design I'm comfortable with.
If you are also constrained on upstream bandwidth, continuous recording means you must buy a local hard drive. It costs $100–$200 to buy one that can hold many camera-months of video at good quality, which I find pretty reasonable.
Some folks might want to also upload stuff off-site in case the NVR itself is stolen or destroyed, but I haven't felt the need. There are a bunch of missing features from my system I'd like to add when I have time; that one doesn't make my top 10. YMMV.
[1] https://github.com/scottlamb/moonfire-nvr/blob/master/design...
Overall, we must be coming at this with quite different expectations of what a NVR should do. Not just this but also "when the app fetches a video, the server deletes the ciphertext (in order to be memory efficient)". Some installations of my NVR software are multi-user; I personally use it from multiple devices; etc. So the idea the whole pipeline exists just to transfer event videos to a single Android device results in a system that I would not find useful.
There certainly is space for different approaches. E.g. Frigate's approach is quite different than Moonfire NVR's but obviously is useful in a lot of ways to a lot of people. But my take is that Privastead's approach is going to be pretty niche, and the claim that other NVRs don't offer strong privacy assurance using "end-to-end" (on-prem server to client) encryption is untrue.
Also, I find it inaccurate to say it's mostly implemented in Rust which "provides higher security assurance for the hub". The Amcrest camera you've chosen is essentially developed by a hostile nation-state, and the protocol code you're using to interact with it (ffmpeg) is all written in C, which I find incongruous with the privacy/security goals. In fact, ffmpeg's RTSP and Matroska code is probably the majority of lines of code in the system.
And my main comparison has been with security camera solutions that use their cloud solution to transfer videos (e.g., Ring). I think an open source solution that uses MLS and treats the cloud as fully untrusted is a superior alternative.
Regarding the multi-user support: yes, that's on the to-do list. A nice aspect of MLS is the notion of groups that it provides. In Privastead, each camera will have a separate MLS group and it could add multiple devices/smartphones to the group. The hub will then try to deliver the video to all devices in the group. Many aspects of the multi-user support still needs to be figured out, but it's technically feasible.
Regarding ffmpeg: I agree. I'm aware of it and I have it in my to-do list to replace that with a Rust-based implementation. In fact, I'll be looking into your retina library as one potential replacement. :-)
Yeah. I'm also frustrated with cameras in general. I've commented on this a few times here before, [1] but tl;dr: I don't even know what camera I'd recommend even if I had the perfect open source firmware to flash onto it easily.
> Regarding the multi-user support: yes, that's on the to-do list. A nice aspect of MLS is the notion of groups that it provides. In Privastead, each camera will have a separate MLS group and it could add multiple devices/smartphones to the group. The hub will then try to deliver the video to all devices in the group. Many aspects of the multi-user support still needs to be figured out, but it's technically feasible.
Okay, interesting, yeah that sounds like a significant step up for most folks.
> Regarding ffmpeg: I agree. I'm aware of it and I have it in my to-do list to replace that with a Rust-based implementation. In fact, I'll be looking into your retina library as one potential replacement. :-)
Patches very welcome. It could use more attention than I've been able to give it recently but likely will interact well with your camera model as-is.
Interesting project! As a Rust implementation for Open MLS, secure end-to-end archival, and a TLS vector, having the DIY home camera setup connect to the internet via a Privastead hub eliminates the need for secure tunneling.
I could see this incorporating facial recognition technology and real-time monitoring.
If you've ever seen eigenfaces, they look like early hominids. One method is principal component analysis (PCA) which isolates the major characteristics of a human face in correlating underlying noise to the most essential features of a face.
Of course, Axis will say, that they do this to protect the world from terrorism, CP, and human trafficking.
I also remember reporting a bug that there was a constant “new” badge next to their referral button in-app, despite me clicking on it and reading it (which I though it would make the “new” badge go away) - support kindly explained to me that they have new referral program every week, which is bonkers because the only thing that changes is the date.
I did look into alternatives but didn’t see anything I could easily trust more after Eufy, so I’m looking forward to the future where simple open source software will cover this part of market, because private companies so far seem to just give you crap for as my $$$ as they can extract.
For example:
https://www.friendlyelec.com/index.php?route=product/product...
https://www.friendlyelec.com/index.php?route=product/product...
https://www.armbian.com/nanopi-duo-2/
Then all video can be collected by applications like Shinobi, Zoneminder, Frigate, etc.
https://moeiscool.github.io/Shinobi/
The hardest part would probably be making an enclosure that is solid enough to withstand being exposed to sun, rain, temperature deltas etc. and remain sealed to protect the electronics.
- reliable human detection (not just motion)
- integration via some sort of API or MQTT etc.
This project appears to have no "smarts" in terms of human detection nor APIs which is a shame. Just pure motion detection on its own is ok, but you're going to pick up all sorts of things that you don't care about.
E.g. I have foxes that run around my garden all night. I don't care about those. But the second a human steps into my garden and starts approaching the house in the night, all the perimeter floodlights are activated, in-house lights turn on, a fake-yet-loud barking dog MP3 starts playing and I get pushover notifications on my phone that won't stop until I ACK them etc (to wake me up).
So far, from personal experience, the most reliable way to stop an attempted burglary in-progress is for lights to switch on from inside as they are attempting to force entry.
Wow this setup seems like overkill for a residential setup. I have lived in “bad” neighborhoods before and have never felt the need to get this kind of setup.
The most I have is a single camera pointed at primary ingress/egress point which is configured to upload to Apple iCloud via “HomeKit Secure Video”.
I actually live in a nice neighborhood and this is the problem I think. I am not especially wealthy, but a lot of people in this area are (and not just a bit wealthy, but like absurdly ferarri-owning excess etc). So while crime generally in this area is low, breakins and robbery is unfortunately high.
I am working on the "run faster than the other person when escaping from a bear" approach. Visible deterrents, then more "active" deterrent in terms of automated lights and dog sounds etc, a solid physical security in the hope that they just try to break in to someone else instead.
I caught around a dozen or so car break ins, random trespasses 'looking around' - and a few other things..
Not one of those recordings was going to get police to do anything.
And now that ring / nest etc are everywhere, most people walking the old neighborhood are wearing a hoody covering their head and a 'it's normal now that we had a pandemic mask' of some sort.
Frankly I think it's best to deter with multiple lights and sounds like op mentioned, otherwise you just catch a recording of a minor crime, and it might make you feel good that you could recongnize the person in the video at the corner gas station or bar down the street, but it doesn't let you stop them or do anything to them.
in my small data point experiences, I understand after a hurricane, some parts of Florida had a different police priority announcement, and places like Texas allow the use of force including deadly force to stop a theft of property,
but here having cameras and weapons is not enough, it's actually expected by the 'bad guys'
But in your case I could recommend Frigate, it's got decent detection that can be accelerated with a Google coral TPU. It also integrates really well with home assistant, you could use it for the light triggering you mention.
I personally use Shinobi but it's not really great and constantly asking for money. Especially if you want to use the app.
I went through various brands of cameras and the Nest ones were the only ones that I could actually rely on. I didn't spend Megabucks but even mid-range local IP cams were very unreliable for RTSP (randomly going offline, super-sketchy partially translated apps for set up/config, frozen streams etc)
I am not concerned about Google's use of my data. I'm not important enough for anyone to want to spy on me specifically. Of all the cloud solutions/providers, I probably trust Google to have the technical know-how but also the public scrutiny pressure to do a general decent job (way more than some random rebadged Tuya service or something "in-house" thing). By that I mean things like e2e encrypted, there won't be employees with just random read access, decent engineering practices, proper security, SREs for uptime, and won't have default passwords/no passwords on some random world-readable S3 bucket etc.
And even if someone did manage infiltrate Google, they'd very likely target someone high-value before me - I doubt anyone would be able to exfiltrate all the data for practical reasons of where to put it but also someone at Google noticing additional exabytes of suddenly outbound data before getting shutdown. I'm working on the (perhaps flawed) assumption that a successful & undetected Google hack would be short-lived. You'd go for someone rich and powerful first, not video clips of me taking the rubbish out.
I do have some ring cameras but they're only looking at my front door and I've cut the microphones out of them (they're incredibly sensitive, I could literally hear myself word for word two rooms away).
Most of my cams are TP-Link used in local mode with internet access blocked.
The risk isn't just an evil insider infiltrating Google.
It's also that a lot of home security companies are in the business of having a friendly relationship with the authorities. So if the cops were investigating a fender-bender down the street and they ask Google for your videos? Better hope that living room camera doesn't show anything you wouldn't want the cops to see, because it's getting handed over.
But they've stopped apparently: https://www.wired.com/story/ring-police-rfa-tool-shut-down/
Still, I've disabled the microphones in mine and they only see my front door anyway.
Years ago, I used Motion[0] on a pi, laptop and desktop, configured to sftp the motion-activated images to a remote server. I could check the files upon alert and view them in rapid succession as 'video'. It was a clunky setup but worked, aside from the vulnerability of the computers being physically accessible to unwanted visitors - but for this I'd use nohup & physlock to at least prevent quick access.
This relatively free setup had limitations, mostly due to my lack of skills and resources, but it provided significant consolation and I'd bring it with me while traveling, eg using the laptop setup for hotel rooms, etc. The fact that the great Bezosauron et al wasn't involved, did please me.
Can you point out how your project provides a better security layout than say, Home Assistant? It does appear that there is little concern for encryption between cameras and local networking hubs, but the assumption seems to be that if the device is over a wire it's isolated to the local network, and if it's Wi-Fi it's subject to WPA. So there isn't much desire for additional encryption in that context.
Otherwise, Home Assistant's server/portal is more than capable of encryption beyond the camera's network interface.
Home Assistant seems to provide two options for remote access: https://www.home-assistant.io/docs/configuration/securing/
One option is to expose your instance to the Internet and using TLS/SSL to connect to it remotely. To me, that's risky since any machine exposed to the Internet is going to see more attack attempts and is harder to secure. The second option is to use their cloud. Here, they explain how remote access through their cloud works: https://www.nabucasa.com/config/remote/#security
They also mention its weaknesses:
"Before we talk about weaknesses, know that we will never abuse any weakness unless forced by a government entity. Our approach has one single weakness that is unavoidable: since we own the domain that hosts the remote connection, we are able to issue our own certificate and man-in-the-middle attack (MITM) remote connections. This would allow us to see all data passing through, including authentication tokens."
Privastead's use of MLS provides strong end-to-end encryption. And Privastead is not vulnerable to MITM attacks due to its secure pairing solution. I plan to write more about the security of Privastead including its pairing solution.
I don't buy the cheap storage argument, trading an upfront cost of maybe $100 for all that complexity. And you can still keep archives - and even a reasonable UI - with some off the shelf FUSE driver. Or, less janky, a cron script running rclone or whatever.
Cool project, I just don't see people migrating to it.
The server is untrusted and does not have access to the plaintext of videos. It only receives the ciphertext (encrypted video) and notifies the app to download them. When the app fetches a video, the server deletes the ciphertext (in order to be memory efficient).
Yes, the hub is part of the Trusted Computing Base (TCB). That means that we trust it. If the attacker compromises it and takes full control of the hub, then the attacker has unfettered access to the IP camera.
That being said, if the attacker only manages to take a snapshot of the keys used by the hub for encryption (and nothing more), then the forward secrecy and post-compromise security aspects of MLS comes to our rescue. They ensure that the attacker can only decrypt some of the messages (at most a full video depending on what keys are compromised), but nothing before and after that.
Also, if I were to set this up behind a firewall, would I need to port forward something so I can access it on the road?
Google FCM is used for delivering notifications to the app. The server asks FCM to do so when needed.
If you look at the history of Rust, the crates, cargo-team, etc, it is mostly community maintained.
An example of such community-oriented large project is Bevy.
It was only when libraries, rust itself was mature enough, the big tech companies started get involved (apart from Mozilla of course).
Whenever the project gets big and important enough, it will get attraction from large companies. The same is true for C++, as well.
> However, I could not find one that I could trust due to privacy concerns.
> Many of them upload the plaintext of videos to their servers and none is fully open-source as far as I know.
There's Frigate [1] which is off-cloud, opensource and self-hosted and it does person detection using GPU or Google Coral. It relays camera streams over WebRTC using ssl and works well with Home Assistant [2], which is your self-hosted off-cloud smart home solution.
Then there's moonfire-nvr [3] which is written in rust and less feature complete than frigate.
And then there's sentryshot [4], another option written in rust.
Interestingly, your project got more stars since you posted it on HN than sentryshot has in total, and they have had a product out since 2021 while yours only support a single camera model and has no object detection.
I suppose this reflects how unknown these option are, which is kind of unexpected since googling "rust nvr" lists them all in the first page.
2: https://www.home-assistant.io/
3: https://github.com/scottlamb/moonfire-nvr
4: https://github.com/SentryShot/sentryshot
> The prototype currently has a lot of limitations: mainly that it has only been tested with one IP camera
Since you use rust, you should maybe have a look at retina:
https://github.com/scottlamb/retina
Personally, I use frigate with Home Assistant linked to HomeKit, so I get snapshots & video from frigate straight into my iPhone lock screen as soon as it detects moving people or cars outside my house.
I like these PoE outdoor ones best: IP5M-T1179EW
Indoor PTZ ones: IP4M-1041W
Old wifi outdoor one: IP4M-1026E
I got some with the plastic dome around them but they do not work well at night, especially in weather.
I also have a ridiculous industrial PTZ camera that I put on my roof to watch birds, planes, and boats, and this thing is an absolute beast. I love it. https://www.alibaba.com/product-detail/4k-action-ptz-camera-...
A key design decision for me was using a strong end-to-end encryption scheme between the camera/hub and the app. MLS fit this need perfectly and therefore I came up with the design that is now Privastead.
I was also less concerned with supporting many cameras since all I needed was one camera inside my house. Rather, I wanted a lean solution that I could fully understand and reason about. I will however look more carefully into the NVRs you listed to see if I can borrow some ideas to support more cameras more easily in Privastead.
Excited to see another project, especially in Rust(not for the memes; python env management has bit me a few times when hacking).
One major gripe with frigate that I have is the way it treats detection events as pointers to video files. This makes replicating events off site a major pain.
Persoanlly I go with the Eyeball Entities Omnicam with an Omniscient Systems Xcam-REAM control centre [0].
IMO, audit the hardware for wireless radios (PoE cameras shouldn't have them), and put them on a camera-only VLAN that can only talk to the video server.
Maybe not suitable for super secure TS locations, but in general should be fine for 99% of situations.
On top of decent cameras they also have pretty well-documented API.
And I share your excitement about Rust. :-)
This and my previous comment probably amount to a full Dropbox comment now :)
Can you elaborate on the sending video part -- do you transfer the whole file or a link to the file on the server? Curious about the replication piece I mentioned
It's something I plan to look into at some point.
I feel as though I have protection of getting the feeds to my phone securely, already. And while I'd love to be able to trust exposing Frigate and making it more accessible, I really don't have a need nor would I as the barrier to entry is already low enough to not impose much friction.
My intent isn't to dissuade you (obviously you wrote it for yourself) but I'd be curious if implementing a more secure transport in an existing OSS NVR that has traction was something you considered?
Regarding the limitation you mentioned: I plan to address them. The next task on my plate is to support multiple cameras. :-)
Looking forward to seeing your project progress!
If I do own all the infra, it seems like a lot of extra effort and complexity in the application which could be farmed out to other solutions (I.e. wireguard).
Seems like this project offers a lot of what I had to cobble together. Nice work. I like that it offers encrypted notifications although I don’t use Android so not ready for me yet. I don’t like the Google dependency.
Privastead does not currently send thumbnails as part of the notifications. Performing proper end-to-end encryption on data in push notifications is a bit tricky and I haven't solved that yet. I do have some ideas on how to make that happen though. Once I do, I plan to add thumbnails to push notifications as well.
And thanks for the pointer on Pushover. I'll check it out to see if it can be a replacement for Google FCM.
It’s pretty good and has an extensive ecosystem. The dev can be a bit… feisty though.
It’s very performant and easy to setup. I don’t use the NVR features as I already have an NVR, I essentially just use it for HomeKit integration of my cameras + doorbell.
About HomeKit: yes, HomeKit uses iCloud end-to-end encryption (https://support.apple.com/en-us/102651) and is certainly superior to those systems that don't use encryption at all or just use encryption between the device and their servers. But Privastead has two advantages:
1) Privastead uses MLS for end-to-end encryption, which provides forward secrecy and post-compromise security. iCloud's end-to-end encryption does not. So what does that mean? This is from the link I included earlier:
"If you lose access to your account, only you can recover this data, using your device passcode or password, recovery contact, or recovery key."
If an attacker manages to access your password, recovery key, etc., they'll be able to decrypt all your videos (assuming they have recorded all your encrypted videos). Such an attack is not possible in MLS. Similar to the Signal protocol, MLS uses double ratchet and there is not a single password, recovery code, key, etc. that can decrypt everything.
2) The HomeKit framework and iCloud end-to-end encryption are not fully open source as far as I know. Therefore, we simply have to trust what Apple says about their security and privacy implications. That might be okay for some users, but not others. Privastead is and intends to remain fully open source. IMO, being open source is a critical component of any security/privacy solution that would like to gain users' trust.
If I lose my phone, I want to get all my security footage back by entering my passphrase etc on my new phone.
In other words, I want the “encrypted cloud storage” security model from [1], not the encrypted messaging security model from Signal etc.
Barely. A lot of functionality is gated behind the NVR plugin, which is closed-source and fairly expensive.
> easy to setup
In my experience, it’s easy to set up. But it’s extremely configurable in all the wrong ways and quite difficult to configure in the ways that one might actually want to configure. And the front end is not fantastic IMO: event filtering is extremely weak and scrubbing is bizarre.
Damn that feels exactly like my experience with Zoneminder. I’m sure it is decent software under the hood, but the UX is downright hostile to anyone who just wants to get IP cameras to do very basic motion detection to record some full resolution footage, which feels like the major, obvious use case that should be optimized for.
I am thankful for OSS existing in this realm, but why do so many solutions make the same mistakes? Am I crazy in thinking that a good out of the box experience is important? Is some critical part of the formula locked behind private walls? Something else? Genuinely curious.
But making a good UI for defining object detection zones is hard, so the very first thing that works at all sticks. Or, once you’ve carefully optimized by using the camera’s built in motion detection and having all the streams you could want, supporting software motion detection is an afterthought, and making it configurable in any useful manner is even more of an afterthought. After all, all the cameras you actually use personally have built in detection that works well and also have so many built-in RTSP streams that you never actually had to optimize for the experience of using a camera with a single stream, a somewhat defective implementation of ONVIF, and entirely unusable motion detection. So you make it work, but only using plugins and extensions, and it never becomes pleasant.
Seems silly to pay to upload all my video of my own house to who knows where and struggle to download it back with absurdly sluggish proprietary software when I have perfectly good computers here already. I should be able to check my cameras without waiting 10-30 seconds for loading spinners and I should be able to scrub through time instantly instead of waiting for interminable loading every time I touch the seek control.
What camera hardware are people using for custom setups? Is there anything out there that is wireless but with high quality/security firmware and reasonably priced?
They can do that to your networking gear though but by then hopefully their image has already made it to the cloud.
OTOH our alarm system (Ring) performed very well.
Unfortunately that prompted to police to be less than helpful (they considered it vandalism instead of a burglary and didn't even take prints). And because they didn't enter the house my cameras didn't see their faces so I couldn't try to track them down on my own either. But at least my stuff was ok.
Not open source, and not the cheapest (but not absurd either). App is acceptable.
I have unifi WiFi APs so have all the rest of the hub/controller anyway and trialled one camera but ultimately opted for Nest cameras instead.
I recommend either Ubiquiti or Reolink cameras, both are power-over-Ethernet. Both offer an app that allows connecting back to your equipment. UI will require their Protect software running on one of their local platforms in your house with storage on 1 or more disk drives, while Reolink offers direct storage on microSD on the camera itself, capped at 256GB.
Given the strict physical requirements, you might be looking at battery-backed wireless cameras of the type often found on Amazon, but afaik they will never offer the local storage or control you want.
I will say that surprising things can be accomplished with small drilled holes and a fishtape. Your risk tolerance and how nice the rental are obviously very important factors.
I am super grateful people are starting to work on open source solutions to this stuff :).
I don't think this is true unless you are logging into your router using the ui.com console. Logging in to my UDM POSTs to the local address and works without a WAN connection.
> also push automatically installed updates
I suppose if you've enabled them.
I'm am totally unfamiliar with this, but what level of concern that theGoogs pulls the plug on this service about the time you gain traction?
I have no skin in the game of push notification infrastructure, but we've seen plenty of ShowHNs where a critical part of the Show is a total dependency on a 3rd party shim. While this isn't something like a dependency on a Twitter API that suddenly got yanked, it is still something that devs should really consider. Especially given theGoogs' track record.
Maybe this isn't the case it is a library deeply embedded in the Android ecosystem, but anytime a ShowHN mentions a dependency on theGoog it sets of the SpideySenses