| ▲ | drfloyd51 4 hours ago |
| So… all that data is literally there for any unauthorized person to walk up and take it. It’s not even suitably encrypted on device? Zero trust in anything Flock says. |
|
| ▲ | EvanAnderson 3 hours ago | parent | next [-] |
| I always assumed Flock's security posture was like most other companies. It's nice to see confirmation. I think I should add a "X'); DROP TABLE Cameras;--" bumper sticker to my car now. Couldn't resist: https://github.com/EvanAnderson/whimsy/blob/main/Drop_Table_... |
| |
|
| ▲ | paimapi 3 hours ago | parent | prev | next [-] |
| has been for a long time - there's a sound engineer who developed quite a following (and is fairly involved with local movement hackerspaces) who demo'd how easy it was to hack Flock cameras nearly a year ago: https://www.youtube.com/watch?v=uB0gr7Fh6lY the Flock response has been 'it doesn't count if a Youtuber did it' lol: https://www.youtube.com/watch?v=0ADb-qQ5hMY |
|
| ▲ | stefangordon 2 hours ago | parent | prev | next [-] |
| The devices are entirely open for all practical purposes - but worrying about individual cameras is silly, because they have no meaningful security at all around the API's to access all the cloud data - you can buy law enforcement credentials dirt cheap in dark web marketplaces to log in and track anyone/anywhere you want and access all footage. |
|
| ▲ | runjake 2 hours ago | parent | prev | next [-] |
| My working assumption based on what I hear out of Flock is that they have a public feature set (mass license plate surveillance for LEO) and a covert feature set (even more mass surveillance, beyond license plates and privacy agreements, for intelligence communities). |
| |
| ▲ | leonidasrup 2 hours ago | parent [-] | | The man who would choose security over freedom deserves neither. - Thomas Jefferson
| | |
|
|
| ▲ | glaslong 3 hours ago | parent | prev | next [-] |
| Yep. Clown show. > The hackers said they were able to access the Android system on the camera, and found two partitions—sections of its hard-drive, essentially. A few of these were unencrypted, the hackers said, including one called “vendor” and another called “media.” The latter contained an encryption key that unlocked another part, which contained much of the media—think, the videos and stills—the camera took. > In early 2025, security researcher Jon “GainSec” Gaines reverse engineered a Flock license-plate reader and documented flaws that could be used to gain root-level access. After Gaines disclosed his findings, the company acknowledged the findings but downplayed their severity, writing that the flaws required physical access to the device and that even someone who gained access to a camera “would still not be able to gain access to footage” because images remained on the device only briefly after being transmitted to the cloud. Source: https://www.404media.co/hackers-stole-flocks-camera-software... |
| |
| ▲ | Quinner 3 hours ago | parent | next [-] | | How could anyone possibly physically access a device that is just sitting out in public? | | | |
| ▲ | scottLobster 3 hours ago | parent | prev | next [-] | | TDIL my homebuilt Plex media server is more strongly encrypted than a Flock Camera | | |
| ▲ | bdangubic 3 hours ago | parent [-] | | so is my all-passwords.txt file on my desktop | | |
| ▲ | antonvs 2 hours ago | parent [-] | | My passwords are in an encrypted block in a text file that can be unencrypted inline in an Emacs session with a keystroke sequence that looks like a cat just chased a mouse across the keyboard, and that's before entering the decryption password. To access it, an attacker would first have to learn Emacs. Pretty sure that's a post-quantum level of security. | | |
| ▲ | mmooss 12 minutes ago | parent | next [-] | | They could use an LLM to lookup your HN posts and then to wrangle Emacs. Or just decrypt the text in another application - I doubt Emacs is the only platform for whatever crypto method you use. M-x rot13 ? | |
| ▲ | dpoloncsak 2 hours ago | parent | prev | next [-] | | Obligatory relevant xkcd:
https://xkcd.com/538/ | | |
| ▲ | IAmBroom an hour ago | parent [-] | | It's a forever-fresh reminder about security versus your own government, but for malicious hackers and bots: the physical trip to visit you costs more than half their infrastructure. Encryption matters, even if I would divulge everything long before the wrench appeared. |
| |
| ▲ | syed_qutub3 an hour ago | parent | prev [-] | | [dead] |
|
|
| |
| ▲ | reaperducer 40 minutes ago | parent | prev [-] | | Runs Android. Has (wireless?) internet access. It seems that some enterprising Jolly Roger could start running a public mesh net on top of them without Flock even noticing. |
|
|
| ▲ | 3 hours ago | parent | prev | next [-] |
| [deleted] |
|
| ▲ | FrustratedMonky 4 hours ago | parent | prev | next [-] |
| It is bad. But think the real danger in Flock is the aggregate data, tracking between camaras. So if someone hacks a single camara, they probably don't get much, unless it is pointed right at someone, which is bad. Aren't they selling these as should be pointing at traffic? If they are pointing right at people, like at playgrounds, then they are being installed illegally to begin with ? |
| |
| ▲ | voakbasda 3 hours ago | parent | next [-] | | A network connected device that can be hacked is a small step away from being the first foothold into its server. The fact that on-device security is this atrocious suggests that their server is not any better quality, which means hacking it would probably not take much effort. | | |
| ▲ | FrustratedMonky 3 hours ago | parent [-] | | I don't disagree. But there is some old rule about, even the best security can fail if the device is physically accessible. | | |
| ▲ | overfeed 14 minutes ago | parent [-] | | There are levels to defending against physical attacks, and Flock half-assed theirs by leaving the encryption key right on the file system, according to the reporting. Those more serious about security like Apple, store keys in an "enclave" chip so it can't be easily extracted by an attacker doing the bare minimum |
|
| |
| ▲ | briffle 2 hours ago | parent | prev [-] | | i think this is actually good, because there are differences between the images they found, and security settings that the company claimed. They had not admitted before to tracking people, but their software is clearly submitting them. They had not admitted before to looking at bumper stickers, but turns out they do. I wonder if they could find all cars with Bernie Sanders bumper stickers within X blocks of a polling place.. I can imagine that (or similar queries) might be very useful in the wrong hands. |
|
|
| ▲ | fullstop 4 hours ago | parent | prev | next [-] |
| Is this an older model? I could see them turning off or using weak encryption on media if the hardware couldn't keep up with the amount of data they were writing. |
| |
| ▲ | ryukoposting 3 hours ago | parent | next [-] | | As another commenter pointed out, any cheapo ARM core from the last 10 years could do the job Flock needs it to do, as long as it has a (very cheap and common) crypto engine strapped to it. But, a question for you: even if it was the case that the hardware was the limitation, isn't that also an indictment of Flock? Selling something that cannot exist securely within the bounds of current technology? Or, at a minimum, bad chip selection leading to a compromised design? | |
| ▲ | megous 4 hours ago | parent | prev | next [-] | | I'm in the process of optimizing a bootolader for my various SoC/SBCs and even the cheapest, oldest least powerful SoC from 15 years ago can manage AES-CBC via crypto accelerator at 50 MiB/s. There's no excuse. | | |
| ▲ | fullstop 3 hours ago | parent [-] | | You can achieve 50MiB/s if that's all that you're doing. I've worked with some DSPs (TI's DaVinci line) where some operations would abort if DDR was overwhelmed. For example, passing a frame of video (YUV) into the peripheral which can resize the overall image, would fail if the system was busy with other DMA transfers. You could attempt to resize again, but there were no guarantee that it would complete successfully. Your options are to reduce overall DDR utilization or drop frames. In an application like Flock's, dropping frames is likely something they need to avoid. The system in question is doing similar tasks, and I don't think that what I'm suggesting is out of the question. | | |
| ▲ | megous 2 hours ago | parent [-] | | They can choose the SoC that would be able to fill the requirements. Eg. almost all Rockchip SoCs have NoC with configurable QoS on master ports (even the cheapest IP camera targetted SoCs that cost like 2-3$), or some other interconnect mechanism that can make it so that SDRAM controller gets tasks in some user selected priority order (eg. you deprioritize CPU in favor of camera interface and other things). This is not a new tech. It already existed when Flock was founded. And in any case. Passing compressed video streams or pictures through HW encryption engine will not saturate 1.5+ GiB/s or whatever even the lousiest 16-bit DDR3 at 400MHz would give you, not even close. It would be like a fraction of a percent of total bandwidth. | | |
|
| |
| ▲ | ohyoutravel 4 hours ago | parent | prev [-] | | That would be an extremely bad trade. | | |
| ▲ | fullstop 3 hours ago | parent [-] | | Why? Does Flock really care about encryption? It checks off a box for their sales team, even if it's done poorly. | | |
| ▲ | samudrijan 3 hours ago | parent [-] | | Because data should be secure. Full stop. | | |
| ▲ | fullstop 2 hours ago | parent | next [-] | | In a perfect world, yes, but this is a for-profit company and there's almost zero repercussion for doing it half-assed. They'd have to pay someone to implement it, and deal with the overhead and complexity. Now they are in a position where they can sell new models with enhanced encryption and more features. | |
| ▲ | criddell 2 hours ago | parent | prev [-] | | If it increases development or operating costs by $1 they won't do it unless there are consequences that could cost them more than that. |
|
|
|
|
|
| ▲ | xnx 3 hours ago | parent | prev [-] |
| > all that data is literally there for any unauthorized person to walk up and take it. All that data about ... license plates if you're willing to steal/damage private property. Seems like it would be a lot easier to setup your own ALPR. |
| |
| ▲ | antonvs 2 hours ago | parent | next [-] | | You don't think that because it's called a "license plate reader," that it only captures license plates, do you? Flock cameras capture the make, model, color, and body style of vehicles. They capture bumper stickers and other decals, as well as potentially identifying dents and scratches. They capture accessories like roof racks, bike racks, trailers, and toolboxes. The OP story covers some of this. There's more at: https://www.aclu.org/campaigns-initiatives/get-the-flock-out https://www.nytimes.com/2026/08/10/us/flock-cameras-can-trac... | |
| ▲ | DANmode an hour ago | parent | prev [-] | | License plate data is bad enough (and unconstitutional in many jurisdictions, despite ubiquity). |
|