the term "pizzagate" was part of the disinformation to throw the actual investigation under the bus.
The press focused on a leaked report that it all happened in a small pizza place. While it effectively (for the leakers) killed progress of the investigation (the one which consequences are being talked now in this thread, so it was very much real) it also gave a catchy name for a while, that cause real investigative reports to jump in.
fake news is a very interesting problem to follow.
Also, the fact that Coinbase is in the US legal jurisdiction gives its clients confidence they would be made whole if anything untoward were to happen.
If the untoward event is solely in USD, perhaps, but not if it's in crypto. Exit scams, hacks, rogue employees, etc, could still hit a US exchanges' crypto holdings and the government probably cannot or will not compell a roll back, supply expansion, etc, on a major blockchain.
If anything is actually protecting clients against crypto theft, it's the exchange's privately-purchased insurance rather than the government. Although I wouldn't rely on that for much either as insurers are rarely eager to pay out.
The 'wealthy' and corporations have the finances to pay for accountants and attorneys to set these things up. Most of them are taking advantage of what is legally already there, but no where near common knowledge. Wading through tax code is a struggle at best.
"Hey company in shenzen that i suspect is a shady front to illegal data mining business, do you have any data on me? i'm john doe, living at 123 naive st #42, phone number 555-555-555, national registry number 1234556. You can reply to me on this same email address. thank you. PS: maybe i filled this in an webform, so please do not attach this new info to all the traffic/behaviour you previously collected from your TV on this same IP address"
This is still logging everything the GDPR says you can't without asking for consent, but you made your search convoluted (but not less efficient if you have all the pieces) to (suggest|lie?) that you need to break the hash and that's why you don't need consent.
None of the information you are using on the hash wouldn't be in the search query itself! ip, user agent, path, date, etc. So there is no way to reverse the hash. You just hash your search query and compare in O(1) time.
The only piece of information that realistically makes the hash slightly difficult to get is the random number refreshed every day. But either you store it (and i have no reason to believe you do not) or it make the brute force effort trivial as I only need to generate the hash with that variable now.
You're focused mostly on Recital 26, which was only a theory of mine, outside of that we are GDPR compliant anyway. I likely shouldn't have included it since that isn't our primary ground for processing. Please see: https://usefathom.com/data/
And yes the daily hash gets stored until midnight. But what are you talking about with 'search query' containing IP, user agent etc.?
If a search query on your data would contain all the components of the original hash, i don't have to walk backwards and break the hash. i just have to hash my query terms in the same way.
Also I suggested you store the daily hash forever. But even if you really erase it every day, as you say, If you or an attacker makes the same request every day at a predetermined time, when you/they get your logs, you/they can use that predictable request to get the daily secret too.
I consider the information to be stored in plain text, and that you would have to have requested permission just the same. You pretty much have an identifiable user (via IP/UA/access time) stored in your logs.
Anonymization is removal of information, not encoding it in a convoluted hash.
So that needs to be our next target point (access logs). We want to move to a position to keep no access lgos.
And a hacker could indeed "win" if they broke into our system, got the salt and exported the DB. We didn't focus on this in our article, as it's unbelievably unrealistic, but it's still possible. Our next step is to address that.
Without the hash, it's practically impossible to brute force.
Not talking about a hacker. I am stating that the described hash dance offers no exclusion from GDPR as saying "we promise we won't look" would do.
My point about brute forcing being useless, is that you hold all the information needed to re-create the hash. All but one tiny piece that is the random number. so brute force is a very effective O(<tiny piece size>). And since it is stored in your locally available data, there is no rate constraints.
> I am stating that the described hash dance offers no exclusion from GDPR as saying "we promise we won't look" would do.
Under your logic, you would never trust us because we could just add $log->write(UserIp, UserAgent, Hostname, Path) in plain text. Trust is very important and what you do with the data is important under GDPR.
And we don't hold all the information to re-create the hash, that's the thing.
I thought a lot about "Oh but you could just do this, this and this" but, no, that argument doesn't hold. Our obligation under GDPR is what we actually do with data.
You think in terms of theoretical society that is either On or Off. No place is like that.
You missed the point that the people fleeing is already stealing tax and are likely the bad parts of the system themselves. They are fleeing from others like them and the justice, to begin with. If the system will collapse or not, i doubt that cross their mind.
In my experience this isn't caused by exhausting the endurance of the flash. It seems like a lot of SD cards have really buggy firmware. And that Linux running on a RPi is particularly prone to triggering these bugs. Industrial SD cards seem to hold up better.
Early iterations of the RPi boards apparently had some bad design choices in the power circuitry, which makes the problem worse.
I have three RPis in abusive conditions, and they haven't had a single SD card issue. Two RPi 3b's running as a car entertainment system, with no form of battery backup/safe shutdown. They are on the ignition power, and once the car turns off, they hard shut down. These have been in place for nearly 2 years with the same Samsung Evo 16GB cards.
The other is attached to a digital signage with less frequent hard shut downs, but still has at least one per week, and been in place since late 2017. Also running a Samsung Evo card (I think it's a 32GB since that's what I had on hand).
Both have high quality power supplies, which may help. The in-car systems have Anker car USB chargers that have been de-cased and soldered in place, while the signage one has an Anker wall charger and a standard micro-b cable.
What's the write cycle like? Seems like those would mostly be read only.
The cards that die quickest for me are either written excessively like a GoPro or Pi based data loggers written constantly. The GoPros are just burning out the cards but the data loggers corrupt the disk images during unexpected power loss.
FWIW I have several Pis running 24x7 and have not had a single SD card failure. I usually buy high end cards but I also buy cheap cards (4GB cards)and a few Micro-Center house brand, for which I don't know the quality.
I've had one that has been running years, I think. Drives a monitor, looping a video where my wife works.
The only SD card failure I have experiences was in a camera.
The press focused on a leaked report that it all happened in a small pizza place. While it effectively (for the leakers) killed progress of the investigation (the one which consequences are being talked now in this thread, so it was very much real) it also gave a catchy name for a while, that cause real investigative reports to jump in.
fake news is a very interesting problem to follow.