Skip to main content
Examples
Source Link

If you feelI totally grasp your desire to capture that strongly,data. So anonymize them. The general idea is you take an MD5 hash of their lowercased email address, and grab as many bits of resolution as you need, and either leave them b7R+ or convert to "AOL passwords" like shave-pen-osram.

Forbidden

   John Smith           FAIL
   Frank Frink          FAIL
   Juliana Crain        PASS
   

What you might be allowed

   Rufus-Castle-Uniform-Enemy    FAIL
   Zion-Lathe-Shoot-Loyal        FAIL
   Flee-Worldly-Variable-Key     PASS
     

What is safer still

   Bucket Stop-Bad         4/6 failed (66%)
   Bucket Wax-Scissors     5/6 failed (83%)
   Bucket Memory-Egg       4/5 failed (80%)

There are two ways to go as far as anonymity, imagining n bits can contain the number of employees (e.g. employees=700 n=10).

  • You can go a few extra bits, like n+6 bits, in which case the anonymization would be reversible and the employee could be exposed: Rufus-Castle-Uniform-Enemy usually hashes out only to [email protected]... Gotcha! There might be a second email, but the more bits, the less likely.
  • You can go a few too few bits, like n-3 bits, in which case, the reverse run will reveal Stop-NukeBad hashes out to jsmith, emccarthy, jcrian, tkido, ctagawa, and ffrink, making retribution impracticable. This winds up creating a group of "buckets" as it were.
  • you can salt the MD5, but that fails if the persecutor
    • learns the salt via a brute-force crypto attack
    • simply commands you to turn it over
    • notes the pattern of activities which has been logged, and deduces the user

Your disagreement with their reasons is a classic workplace.se problem, but they may not be telling you all their reasons*. Regardless you must comply in your report to them.

The methods I've provided here with anonymization allow you to present, in your report, the detail data you want to present, while technically complying with their directive. You can either do it in the n+many form, which allows them to backtrack to individual users if they really want to -- or the bucketed form, which does not.

Bucketing is fairly useless at 70% unless you present "In bucket 127, 4/6 users fell for the phish". Bucketing works best when the hit rate is 1/3 the number of buckets or less, so 2 hits in the same bucket are rare. "In 512 buckets, 90 buckets had hits, most likely that's 90-95 people, which is the number you want.

* as a litigator I can think of a really big one. If it were me, I would delete the personalized data "as a matter of routine". Saving everything forever is all fun and games until the subpoena comes.

If you feel that strongly, anonymize them. The general idea is you take an MD5 hash of their lowercased email address, and grab as many bits of resolution as you need, and either leave them b7R+ or convert to "AOL passwords" like shave-pen-osram.

There are two ways to go as far as anonymity, imagining n bits can contain the number of employees (e.g. employees=700 n=10).

  • You can go a few extra bits, like n+6 bits, in which case the anonymization would be reversible and the employee could be exposed: Rufus-Castle-Uniform-Enemy usually hashes out only to [email protected]... Gotcha! There might be a second email, but the more bits, the less likely.
  • You can go a few too few bits, like n-3 bits, in which case, the reverse run will reveal Stop-Nuke hashes out to jsmith, emccarthy, jcrian, tkido, ctagawa, and ffrink, making retribution impracticable. This winds up creating a group of "buckets" as it were.
  • you can salt the MD5, but that fails if the persecutor
    • learns the salt via a brute-force crypto attack
    • simply commands you to turn it over
    • notes the pattern of activities which has been logged, and deduces the user

Your disagreement with their reasons is a classic workplace.se problem, but they may not be telling you all their reasons*. Regardless you must comply in your report to them.

The methods I've provided here with anonymization allow you to present, in your report, the detail data you want to present, while technically complying with their directive. You can either do it in the n+many form, which allows them to backtrack to individual users if they really want to -- or the bucketed form, which does not.

Bucketing is fairly useless at 70% unless you present "In bucket 127, 4/6 users fell for the phish". Bucketing works best when the hit rate is 1/3 the number of buckets or less, so 2 hits in the same bucket are rare. "In 512 buckets, 90 buckets had hits, most likely that's 90-95 people, which is the number you want.

* as a litigator I can think of a really big one. If it were me, I would delete the personalized data "as a matter of routine". Saving everything forever is all fun and games until the subpoena comes.

I totally grasp your desire to capture that data. So anonymize them. The general idea is you take an MD5 hash of their lowercased email address, and grab as many bits of resolution as you need, and either leave them b7R+ or convert to "AOL passwords" like shave-pen-osram.

Forbidden

   John Smith           FAIL
   Frank Frink          FAIL
   Juliana Crain        PASS
   

What you might be allowed

   Rufus-Castle-Uniform-Enemy    FAIL
   Zion-Lathe-Shoot-Loyal        FAIL
   Flee-Worldly-Variable-Key     PASS
     

What is safer still

   Bucket Stop-Bad         4/6 failed (66%)
   Bucket Wax-Scissors     5/6 failed (83%)
   Bucket Memory-Egg       4/5 failed (80%)

There are two ways to go as far as anonymity, imagining n bits can contain the number of employees (e.g. employees=700 n=10).

  • You can go a few extra bits, like n+6 bits, in which case the anonymization would be reversible and the employee could be exposed: Rufus-Castle-Uniform-Enemy usually hashes out only to [email protected]... Gotcha! There might be a second email, but the more bits, the less likely.
  • You can go a few too few bits, like n-3 bits, in which case, the reverse run will reveal Stop-Bad hashes out to jsmith, emccarthy, jcrian, tkido, ctagawa, and ffrink, making retribution impracticable. This winds up creating a group of "buckets" as it were.
  • you can salt the MD5, but that fails if the persecutor
    • learns the salt via a brute-force crypto attack
    • simply commands you to turn it over
    • notes the pattern of activities which has been logged, and deduces the user

Your disagreement with their reasons is a classic workplace.se problem, but they may not be telling you all their reasons*. Regardless you must comply in your report to them.

The methods I've provided here with anonymization allow you to present, in your report, the detail data you want to present, while technically complying with their directive. You can either do it in the n+many form, which allows them to backtrack to individual users if they really want to -- or the bucketed form, which does not.

Bucketing is fairly useless at 70% unless you present "In bucket 127, 4/6 users fell for the phish". Bucketing works best when the hit rate is 1/3 the number of buckets or less, so 2 hits in the same bucket are rare. "In 512 buckets, 90 buckets had hits, most likely that's 90-95 people, which is the number you want.

* as a litigator I can think of a really big one. If it were me, I would delete the personalized data "as a matter of routine". Saving everything forever is all fun and games until the subpoena comes.

added 65 characters in body
Source Link

If you feel that strongly, anonymize them. The general idea is you take an MD5 hash of their lowercased email address, and grab as many bits of resolution as you need, and either leave them b7R+ or convert to "AOL passwords" like shave-pen-osram.

There are two ways to go as far as anonymity, imagining n bits can contain the number of employees (e.g. employees=700 n=10).

  • You can go a few extra bits, like n+6 bits, in which case the anonymization would be reversible and the employee could be exposed: Rufus-Castle-Uniform-Enemy usually hashes out only to [email protected]... Gotcha! There might be a second email, but the more bits, the less likely.
  • You can go a few too few bits, like n-3 bits, in which case, the reverse run will reveal Stop-Nuke hashes out to jsmith, emccarthy, jcrian, tkido, ctagawa, and ffrink, making retribution impracticable. This winds up creating a group of "buckets" as it were.
  • you can salt the MD5, but that fails if the persecutor
    • learns the salt via a brute-force crypto attack
    • simply commands you to turn it over
    • notes the pattern of activities which has been logged, and deduces the user

Your disagreement with their reasons is a classic workplace.se problem, but they may not be telling you all their reasons*. Regardless you must comply in your report to them.

The methods I've provided here with anonymization allow you to present, in your report, the detail data you want to present, while technically complying with their directive. You can either do it in the n+many form, which allows them to backtrack to individual users, if they really want to -- or the bucketed form, which does not.

Bucketing is fairly useless at 70% unless you present "In bucket 127, 4/6 users fell for the phish". Bucketing works best when the hit rate is 1/3 the number of buckets or less, so 2 hits in the same bucket are rare. "In 512 buckets, 90 buckets had hits, most likely that's 90-95 people, which is the number you want.

* as a litigator I can think of a really big one. If it were me, I would delete the personalized data "as a matter of routine". Saving everything forever is all fun and games until the subpoena comes.

If you feel that strongly, anonymize them. The general idea is you take an MD5 hash of their lowercased email address, and grab as many bits of resolution as you need, and either leave them b7R+ or convert to "AOL passwords" like shave-pen-osram.

There are two ways to go as far as anonymity, imagining n bits can contain the number of employees (e.g. employees=700 n=10).

  • You can go a few extra bits, like n+6 bits, in which case the anonymization would be reversible and the employee could be exposed: Rufus-Castle-Uniform-Enemy usually hashes out only to [email protected]... Gotcha! There might be a second email, but the more bits, the less likely.
  • You can go a few too few bits, like n-3 bits, in which case, the reverse run will reveal Stop-Nuke hashes out to jsmith, emccarthy, jcrian, tkido, ctagawa, and ffrink, making retribution impracticable. This winds up creating a group of "buckets" as it were.
  • you can salt the MD5, but that fails if the persecutor
    • learns the salt via a brute-force crypto attack
    • simply commands you to turn it over
    • notes the pattern of activities which has been logged, and deduces the user

Your disagreement with their reasons is a classic workplace.se problem, but they may not be telling you all their reasons*. Regardless you must comply.

The methods I've provided here with anonymization allow you to present the detail data you want to present, while technically complying with their directive. You can either do it in the n+many form, which allows them to backtrack to individual users, or the bucketed form, which does not.

Bucketing is fairly useless at 70% unless you present "In bucket 127, 4/6 users fell for the phish". Bucketing works best when the hit rate is 1/3 the number of buckets or less, so 2 hits in the same bucket are rare. "In 512 buckets, 90 buckets had hits, most likely that's 90-95 people, which is the number you want.

* as a litigator I can think of a really big one. If it were me, I would delete the personalized data "as a matter of routine". Saving everything forever is all fun and games until the subpoena comes.

If you feel that strongly, anonymize them. The general idea is you take an MD5 hash of their lowercased email address, and grab as many bits of resolution as you need, and either leave them b7R+ or convert to "AOL passwords" like shave-pen-osram.

There are two ways to go as far as anonymity, imagining n bits can contain the number of employees (e.g. employees=700 n=10).

  • You can go a few extra bits, like n+6 bits, in which case the anonymization would be reversible and the employee could be exposed: Rufus-Castle-Uniform-Enemy usually hashes out only to [email protected]... Gotcha! There might be a second email, but the more bits, the less likely.
  • You can go a few too few bits, like n-3 bits, in which case, the reverse run will reveal Stop-Nuke hashes out to jsmith, emccarthy, jcrian, tkido, ctagawa, and ffrink, making retribution impracticable. This winds up creating a group of "buckets" as it were.
  • you can salt the MD5, but that fails if the persecutor
    • learns the salt via a brute-force crypto attack
    • simply commands you to turn it over
    • notes the pattern of activities which has been logged, and deduces the user

Your disagreement with their reasons is a classic workplace.se problem, but they may not be telling you all their reasons*. Regardless you must comply in your report to them.

The methods I've provided here with anonymization allow you to present, in your report, the detail data you want to present, while technically complying with their directive. You can either do it in the n+many form, which allows them to backtrack to individual users if they really want to -- or the bucketed form, which does not.

Bucketing is fairly useless at 70% unless you present "In bucket 127, 4/6 users fell for the phish". Bucketing works best when the hit rate is 1/3 the number of buckets or less, so 2 hits in the same bucket are rare. "In 512 buckets, 90 buckets had hits, most likely that's 90-95 people, which is the number you want.

* as a litigator I can think of a really big one. If it were me, I would delete the personalized data "as a matter of routine". Saving everything forever is all fun and games until the subpoena comes.

added 764 characters in body
Source Link

If you feel that strongly, anonymize them. The general idea is you take an MD5 hash of their lowercased email address, and grab as many bits of resolution as you need, and either leave them b7R+ or convert to "AOL passwords" like shave-pen-osram.

There are two ways to go as far as anonymity, imagining n bits can contain the number of employees (e.g. employees=700 n=10).

  • You can go a few extra bits, like n+6 bits, in which case the anonymization would be reversible and the employee could be exposed: Rufus-Castle-Uniform-Enemy usually hashes out only to [email protected]... Gotcha! There might be a second email, but the more bits, the less likely.
  • You can go a few too few bits, like n-3 bits, in which case, the reverse run will reveal Stop-Nuke hashes out to jsmith, emccarthy, jcrian, tkido, ctagawa, and ffrink, making retribution impracticable. This winds up creating a group of "buckets" as it were.
  • you can salt the MD5, but that fails if the persecutor
    • learns the salt via a brute-force crypto attack
    • simply commands you to turn it over
    • notes the pattern of activities which has been logged, and deduces the user

Suffice it to sayYour disagreement with their reasons is a classic workplace.se problem, but they may not be telling you now have anonymized the dataall their reasons*. EvenRegardless you must comply.

The methods I've provided here with the n-3 bits solution,anonymization allow you still are able to get a general window of the depth ofpresent the problem. E.gdetail data you want to present, while technically complying with their directive. You can either do it in each of the 128 bucketsn+many form, at least 1 user fell for the phishwhich allows them to backtrack to individual users, or eventhe bucketed form, which does not.

Bucketing is fairly useless at 70% unless you present "In bucket 127, 4/6 users fell for the phish". Bucketing works best when the hit rate is 1/3 the number of buckets or less, so 2 hits in the stop-nukesame bucket fell forare rare. "In 512 buckets, 90 buckets had hits, most likely that's 90-95 people, which is the phish (ifnumber you are willing to expose thatwant.

* as a litigator I can think of a really big one. If it were me, I would delete the personalized data) "as a matter of routine". Saving everything forever is all fun and games until the subpoena comes.

If you feel that strongly, anonymize them. The general idea is you take an MD5 hash of their lowercased email address, and grab as many bits of resolution as you need, and either leave them b7R+ or convert to "AOL passwords" like shave-pen-osram.

There are two ways to go as far as anonymity, imagining n bits can contain the number of employees (e.g. employees=700 n=10).

  • You can go a few extra bits, like n+6 bits, in which case the anonymization would be reversible and the employee could be exposed: Rufus-Castle-Uniform-Enemy usually hashes out only to [email protected]... Gotcha!
  • You can go a few too few bits, like n-3 bits, in which case, the reverse run will reveal Stop-Nuke hashes out to jsmith, emccarthy, jcrian, tkido, ctagawa, and ffrink, making retribution impracticable. This winds up creating a group of "buckets" as it were.
  • you can salt the MD5, but that fails if the persecutor
    • learns the salt via a brute-force crypto attack
    • simply commands you to turn it over
    • notes the pattern of activities which has been logged, and deduces the user

Suffice it to say, you now have anonymized the data. Even with the n-3 bits solution, you still are able to get a general window of the depth of the problem. E.g. in each of the 128 buckets, at least 1 user fell for the phish, or even 4/6 users in the stop-nuke bucket fell for the phish (if you are willing to expose that data).

If you feel that strongly, anonymize them. The general idea is you take an MD5 hash of their lowercased email address, and grab as many bits of resolution as you need, and either leave them b7R+ or convert to "AOL passwords" like shave-pen-osram.

There are two ways to go as far as anonymity, imagining n bits can contain the number of employees (e.g. employees=700 n=10).

  • You can go a few extra bits, like n+6 bits, in which case the anonymization would be reversible and the employee could be exposed: Rufus-Castle-Uniform-Enemy usually hashes out only to [email protected]... Gotcha! There might be a second email, but the more bits, the less likely.
  • You can go a few too few bits, like n-3 bits, in which case, the reverse run will reveal Stop-Nuke hashes out to jsmith, emccarthy, jcrian, tkido, ctagawa, and ffrink, making retribution impracticable. This winds up creating a group of "buckets" as it were.
  • you can salt the MD5, but that fails if the persecutor
    • learns the salt via a brute-force crypto attack
    • simply commands you to turn it over
    • notes the pattern of activities which has been logged, and deduces the user

Your disagreement with their reasons is a classic workplace.se problem, but they may not be telling you all their reasons*. Regardless you must comply.

The methods I've provided here with anonymization allow you to present the detail data you want to present, while technically complying with their directive. You can either do it in the n+many form, which allows them to backtrack to individual users, or the bucketed form, which does not.

Bucketing is fairly useless at 70% unless you present "In bucket 127, 4/6 users fell for the phish". Bucketing works best when the hit rate is 1/3 the number of buckets or less, so 2 hits in the same bucket are rare. "In 512 buckets, 90 buckets had hits, most likely that's 90-95 people, which is the number you want.

* as a litigator I can think of a really big one. If it were me, I would delete the personalized data "as a matter of routine". Saving everything forever is all fun and games until the subpoena comes.

added 243 characters in body
Source Link
Loading
Source Link
Loading