Isn't this just a way to confirm that your email is still active, and few miliseconds later you will be getting a lot of new spam from websites you never knew about?
Show HN: Auto-identity-remove – Automated data broker opt-out runner for macOS
121–130 of 147 posts
Re: Show HN: Auto-identity-remove – Automated data broker opt-out runner for macOS
#122Earlier quoted context omitted.
> 2. It asks for access to your email via Apple's Mail app which I don't use Assumption that people use Apple services by default is wild
The mail app is a native Mac app but it can use any email account. It's an SMTP/IMAP/POP client.
True. But Apple also enshittified the UI and they had an unforgivable data loss issue with Mail back in the Catalina days, which is why I switched to Thunderbird and haven't looked back.
Re: Show HN: Auto-identity-remove – Automated data broker opt-out runner for macOS
#123Re: Show HN: Auto-identity-remove – Automated data broker opt-out runner for macOS
#124Back in 2011 or so the Yellow Pages still delivered physical phone books to ever address in the state where we were. My city literally sent out an extra off cycle recycling truck the next day to pick them all up. Everyone threw them out. Well my coworkers and I realized that the opt out form just needed an address. We contemplated pulling all known addresses for the entire country and automating submitting them all o…
> I don’t think it ever materialized but we had a good chuckle about the emergency meeting the Yellow Pages web devs would have had and at what percentage of opt outs. They would just pretend they didn't receive the opt outs, like half of the direct mailers and spammers out there. I've gone through the trouble of trying to get Uline to stop sending gigantic paper catalogs to my PO Box two or three times per year. The…
One day many years ago, I saw an item that I did an impulse buy on. It wasn't an ad, but just lame ol' bored surfing discovery. I never even saw the rest of the site the item was bought from. Later I started receiving printed catalogs from the site. It followed me through 3 moves, and I never used USPS forwarding. I assume the site eventually died as the catalogs just stopped showing up
Re: Show HN: Auto-identity-remove – Automated data broker opt-out runner for macOS
#125Earlier quoted context omitted.
recaptcha v3 will require the human to have a Google certified android device (i.e. no GrapheneOS or LineageOS etc.) and a dedicated iOS app which leaks device ID and other data. Google will get to know every user browsing the web and link it to a smartphone. Since they’re rolling out government issue ID verification at the OS level, this change will allow Google to identify a random web visitor to a govt ID. https:/…
More info on how an iOS app can leak device ID? I thought Apple did away with access to device IDs and only provides a per-developer ID.
It’s in the Apple app store App Privacy disclosure [1]
Location (“coarse location”), identifiers (“device id, user id”)
^ both are deemed a necessity for app functionality, with deviceID required for analytics too.
Re: Show HN: Auto-identity-remove – Automated data broker opt-out runner for macOS
#126Earlier quoted context omitted.
Sounds pretty much like they're identify the device, then. Or is "device id" Apple lingo for a specific tech?
No, on both android and ios device id implies some sort of identifier that's reusable across apps. Otherwise a uuid that you generate and write to storage could qualify as a "device id".
So, essentially a super cookie? That is, generated once (at random or arbitrarily) and then included with proof of work? But not a fingerprint or otherwise linked to identity?
But then that would not work against correlating fraud detection as sketched above. A client could simply reset the app every now and then to generate a new UUID.
Re: Show HN: Auto-identity-remove – Automated data broker opt-out runner for macOS
#127Earlier quoted context omitted.
No, on both android and ios device id implies some sort of identifier that's reusable across apps. Otherwise a uuid that you generate and write to storage could qualify as a "device id".
So, essentially a super cookie? That is, generated once (at random or arbitrarily) and then included with proof of work? But not a fingerprint or otherwise linked to identity? But then that would not work against correlating fraud detection as sketched above. A client could simply reset the app every now and then to generate a new UUID.
>So, essentially a super cookie? That is, generated once (at random or arbitrarily) and then included with proof of work?
You're just describing a regular cookie.
>But not a fingerprint or otherwise linked to identity?
You'll have to reverse-engineer the app to figure out whether it's actually fingerprinting, and whether it's fingerprinting to make sure it's a real device (vs emulator) or it's fingerprinting to uniquely identify someone. I suspect they're complying with app store guidelines and not doing the latter, because it's not worth the PR hit to just to vaguely improve a product responsible for >But then that would not work against correlating fraud detection as sketched above. A client could simply reset the app every now and then to generate a new UUID.
The attestation result contains a count of attested keys generated in the past 30 days, which detects this case without a "supercookie" that persists across uninstalls.
https://developer.apple.com/documentation/devicecheck/assess...
Re: Show HN: Auto-identity-remove – Automated data broker opt-out runner for macOS
#128Earlier quoted context omitted.
So, essentially a super cookie? That is, generated once (at random or arbitrarily) and then included with proof of work? But not a fingerprint or otherwise linked to identity? But then that would not work against correlating fraud detection as sketched above. A client could simply reset the app every now and then to generate a new UUID.
>So, essentially a super cookie? That is, generated once (at random or arbitrarily) and then included with proof of work? You're just describing a regular cookie. >But not a fingerprint or otherwise linked to identity? You'll have to reverse-engineer the app to figure out whether it's actually fingerprinting, and whether it's fingerprinting to make sure it's a real device (vs emulator) or it's fingerprinting to uniqu…
> You're just describing a regular cookie.
Yes regular cookie from Google's perspective, but super in that it works across sites. If for some reason you don't just take Google's word you might suspect they collude and share / sell your identity to the site as well...
> The attestation result contains a count of attested keys generated in the past 30 days, which detects this case without a "supercookie" that persists across uninstalls.
Ah. So there is something special limiting control over the UUID? Or is there some way of correlating the physical device to the attestation history?
Why wouldn't I be able to reset and re-enroll in the app and then have it generate me a fresh new cookie attestation history?
Re: Show HN: Auto-identity-remove – Automated data broker opt-out runner for macOS
#129Earlier quoted context omitted.
The mailroom of my apartment building in college in 1988 was full of phone books that were unclaimed. I took enough to make a platform for my futon.
As funny as these stories are it makes my environmentalist blood boil. Such ridiculous waste at scale for a product barely anyone actually wants.
Pre-internet the commercial phone book was actually fairly useful. The "problem" was that most people didn't need it updating as often as the phone book company would have liked.
Re: Show HN: Auto-identity-remove – Automated data broker opt-out runner for macOS
#130The only thing that is tied to MacOS is launchd, seems like that's useful info to add to the docs. I don't know if you can just do a run from the CLI. Supporting Systemd should be easy. Not sure what windows uses.
Creating a Windows service is a bit harder (as Windows actually uses a real API for services rather than just relying on process spawning and scripting around that), but with task scheduler you can schedule tasks to run once a month in all kinds of ways.
A Windows Service is something you (generally) want running 24x7. In fact I think a Windows Service seems very much like the wrong thing to do here. Services are not the only way to schedule things in Windows.
And you can "just" use nssm to wrap any arbitrary executable with what is needed to make it a windows service.
edit: Windows can use Node and Playwright just fine. I think the only thing this needs a Mac for is to schedule and send messages as an alert.