Hacker News new | past | comments | ask | show | jobs | submit | bmistree's comments login

From the little I've read on the topic, there are many good reasons to be skeptical of the 600,000 copy figure cited here.

This [0] article summarizes some of the debate.

At a high level, the number seems to be derived from Thomas Paine's assertions that he sold 120,000 copies in the first three months of Common Sense's release. However, Paine had no way to measure this number and likely didn't even have a way to reasonably estimate it.

The article mentions a historian that analyzed data from the time (number of known printings and maximum batch size for a print run): "Putting all this together–twenty-five printings at a maximum of 3,000 each (even though most print runs were probably much less), Loughran places the far upper limit at 75,000, but she thinks the true number was much less than that."

I don't know much about Gatto or Dumbing Us Down. However, I personally don't find this quote persuasive, given the uncertainty around the 600k figure.

[0] https://allthingsliberty.com/2013/03/thomas-paines-inflated-...


Let me preface this by stating that I don't actually have any special knowledge of the art or criminal world beyond what I've seen in the movies, so the following is pure speculation.

I could imagine that if a thief's motive were purely financial, he/she could ransom the painting. "This is a priceless piece of world heritage that is heavily insured. Send XXX BTC to this wallet or I'll burn up the painting and send you its ashes."


I just wanted to piggy-back onto the parent’s comment with a concrete example.

I’ve always been told that it’s good practice to take periodic backups. In the absolute worst cases, you can simply restore directly from these.

If a customer requests that their data are deleted, in addition to my production instance, does that mean that I have to remove their data from my backups? If so, I’m uncertain of the best way to do this. I’m uncertain if many managed services will allow me to mutate backups. And even if I were managing my database and backups directly, it seems painful to load each backed up database, remove the data, and rewrite the backup.

Note: I’m not saying that any of this is impossible. However, it does require a lot of ancillary engineering work difficult for a small company that’s just trying to get to product market fit.


Not sure about the legal framework in the US but over here across the pond, it's enough if you remove the data when restoring the backups (reasonably easy to do; took me about a day to implement that on an old codebase that I wrote more than ten years ago, and I haven't touched either PHP or that codebase since then...).

IANAL but the guy who told us how it's done was, and in addition to all the legal stuff, of which I have absolutely no recollection because I don't really understand it, he pointed us to this as a useful resource for people who are also not lawyers: https://ico.org.uk/for-organisations/guide-to-data-protectio... .

Turns out it's acceptable for data to remain backed up for a while (as long as you inform your users), as long as you have systems in place that guarantees it's not used anymore.

Just sayin, it's not rocket science. Reading Internet forums you'd think the GDPR was like Apocalypse Lite, but in my experience, it took very little effort to implement it for companies that weren't engaging in shady practices.


>Not sure about the legal framework in the US but over here across the pond, it's enough if you remove the data when restoring the backups

Implementation-wise, is the best approach to do this to store some token for "user XX requested YY data be deleted" and check those tokens whenever you restore a backup?

I feel like that'd run befoul of a true solution because, in the event of a leak, it could be used to tie the information in the backup to the user who requested their data be deleted. Or am I misunderstanding such that that'd actually be acceptable under GDPR?

Is there a better way to do it?


That's pretty close to what I did, except I didn't reference the user who requested removal -- it's just a token that says "data will be removed due to GDPR request". I think there's a requirement to log removal requests, so there are still dots that can be connected, though.

Also, I don't know if it's the best technical approach -- I did just because it's code that I wrote a very long time ago, for a friend who was just starting their business. I took care of it because we're still friends and he asked me if I could take a look at it, but it's the first time I've done backend/web development in more than 12 years now.

I think this is sufficient, even considering things like the potential for data breaches. It complies with both the explicit requirements and the general spirit of the GDPR. IANAL and all but I think that, since data leaks aren't a form of data processing by the company who collected the information, they are outside the scope of Art. 17. There are already requirements in place about the secure storage and administration of personal data.

Plus, if you think of it, the framework of this whole construction provides sufficient assurance. If you have live, online backups which can be restored immediately, with a single click, then it's clearly not a problem to erase data from them immediately. If you have offline backups, you're required to have a retention policy for them anyway, and you can't process data from them anyway -- not until they're restored and you've had a chance to purge them. It's certainly possible that someone might break into your storage unit and run away with your archive tapes or hard drives or whatever, but at that point there's a lot of legislation that you have to worry about having broken before you even get to the damn GDPR :).


For GDPR it's sufficient to inform about the backups and when they are expected to be deleted. If you restore them you must have procedures in place to delete the requested data. I don't think this is any different.


The ethical challenge this New Yorker article presents is that:

  - Members of the Media Lab knew at least some of Mr. Epstein's transgressions (to the point that some of them were concerned he may have brought trafficked women into the lab)
  - Subsequently solicited funds from him, despite knowledge of these transgressions
  - Actively concealed the source of these funds
Additionally, it seems that members may have intentionally broken MIT administrative policy that disqualified Mr. Epstein as a donor.

I googled around a bit, and maybe didn't find the entanglements that you're referring to. Please correct me if I'm wrong, but I could only find that Harvard accepted money before knowledge of Mr. Epstein's attacks could be expected to be publicly known [1]. Articles also mention personal relationships that Mr. Epstein had with individuals at Harvard. However, those don't seem to have involved Harvard the institution directly.

Again, I could have missed something, but these seem to be different situations. And it makes sense that the Media Lab would attract more attention in this case than Harvard.

[1] https://www.usatoday.com/story/news/nation/2019/07/11/harvar...


4. No actual consequences for anyone demonstrated to be lying.

Until officials are held accountable, why wouldn't they continue lying and denying? It's starting to get to the point where I'm more angry at congress members who should provide oversight, than the lying officials themselves.

As a simple example, if I'm an NSA official and contrast how James Clapper experienced absolutely no real consequences for perjuring himself [1], with how Snowden has been treated for rocking the boat, I honestly don't know what decision I would make.

[1] http://www.salon.com/2013/06/12/how_james_clapper_will_get_a...


Another version of the story posted on CNN [1] has a slightly different version of events.

> Concerned that attorneys did not have all the information they needed to prepare the case, he said, he reported his concerns to a State Attorney's Office investigator and later to prosecutor Bernie de la Rionda.

Ie, before contacting the defense through a lawyer, he talked to the prosecutor in charge of the case as well as an investigator with oversight of the attorney's office. Maybe he should have discussed the matter with the attorney general directly after these first two attempts, but his disclosure seems a little more reasonable knowing that he seemed to make an early effort at following the "chain of command."

As a side note, this article was fairly confusing for me. I had to read key passages several times and I'm still uncertain of the basic sequence of events. Many useful hn comments on this post seem to be just clarifying what the article should have reported in plain language. Ugh.

[1] http://www.cnn.com/2013/07/13/justice/zimmerman-it-firing/in...


I don't really get the argument that President Obama and Candidate Obama were somehow different people.

In 2008, Candidate Obama first promised that he would not vote for retroactive immunity for telecom companies that had opened their networks to the NSA. And then, a matter of weeks later, he did so anyways [1,2].

This vote was inextricably linked to the issues we're discussing today. In 2008, companies were on the verge actual accountability: they would have had to pay millions and billions of dollars in fines to their customers (or at least their customers' lawyers). If that had happened, it's easy to imagine those companies' modern incarnations being more adversarial with regards to new surveillance laws, court orders, and appropriate process.

It was clear then that Candidate Obama would easily cave on core issues for political expedience, just as it is now. I'm not saying that there were better alternative candidates. I'm just saying that if you'd really have followed "2007 Obama anywhere." you either weren't paying attention or willfully deceived yourself.

[1] http://news.cnet.com/8301-10784_3-9982898-7.html [2] http://news.cnet.com/8301-13578_3-9986716-38.html


Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: