231–240 of 277 posts
non-paywall version: http://archive.is/rpuA1
An error occurred during a connection to archive.is. Cannot communicate securely with peer: no common encryption algorithm(s). Error code: SSL_ERROR_NO_CYPHER_OVERLAP
SSLLabs probably has the same problem: https://www.ssllabs.com/ssltest/analyze.html?d=archive.is
>We made Google+ with privacy in mind and therefore keep this API’s log data for only two weeks. That means we cannot confirm which users were impacted by this bug. Wait, so they only keep two weeks worth of logs and within these logs they did not find anyone abusing this flaw. How can they be certain for any time period from two week prior ?
Nowadays I tend to trust a company that had a security vulnerability or data breach once and handled it gracefully, rather than a company that says they had no security breach. Making a mistake is only human; Your true test is what you do after you found it.
>We made Google+ with privacy in mind and therefore keep this API’s log data for only two weeks. That means we cannot confirm which users were impacted by this bug. Wait, so they only keep two weeks worth of logs and within these logs they did not find anyone abusing this flaw. How can they be certain for any time period from two week prior ?
The company which consider every single bit of data as "gold" decided not to keep their API's access log > 2 weeks? wow!
Nowadays I tend to trust a company that had a security vulnerability or data breach once and handled it gracefully, rather than a company that says they had no security breach. Making a mistake is only human; Your true test is what you do after you found it.
Nowadays I tend to trust a company that had a security vulnerability or data breach once and handled it gracefully, rather than a company that says they had no security breach. Making a mistake is only human; Your true test is what you do after you found it.
So is this an example of a company handling it gracefully? They couldn't tell what the impact was but kept it a secret for 6 months.
non-paywall version: http://archive.is/rpuA1
I get a TLS problem: An error occurred during a connection to archive.is. Cannot communicate securely with peer: no common encryption algorithm(s). Error code: SSL_ERROR_NO_CYPHER_OVERLAP SSLLabs probably has the same problem: https://www.ssllabs.com/ssltest/analyze.html?d=archive.is
Earlier quoted context omitted.
User IDs are definitely private info, since they'd allow you to follow a user's behaviour etc.
"user 1234567 viewed post 89564385943" I can see how that's private info, but would this be: "client x viewed user 1234567's profile"
I am not a lawyer. You should hire an appropriately qualified lawyer to review your data hygiene practices.
Earlier quoted context omitted.
Does anyone else get rubbed the wrong way by this sort of irreverent infringement? Even if you have zero concern for journalists’ copyrights, it puts this forum at risk.
Fair use exemption makes specific reference to "purposes such as criticism, comment, news reporting" - those are just the first three listed, and all three apply to a HN post.
Earlier quoted context omitted.
> Our default policy is to keep generic RPC server logs for O(weeks). Out of curiosity, when was this policy adopted? After these security holes were discovered?
Doesn't the statement "That means we cannot confirm which users were impacted by this bug" indicate it was adopted before the hole was discovered?