On Thursday, April 10, 2003, at 11:45 AM, J C Lawrence wrote:
Sure, that's one way (and the way that TMDA does it), but I'd rather notagreed -- I only took it to the point where I understood if it required infrastructure changes or other non-local things, because that significantly impacts workability and complexity. Once we can see a way of building it "in place", we can leave the details for later...
get messed in with implementation of how to encode consent tokens at
this point.
not necessarily. dynamically generate the mailto using SSI, when it's generated the token gets stuffed in the database until it expires. it wouldn't take much more work to do it in a way where tokens weren't generated until "asked for".There are horrors in UI complexity here, but yes, these are the sorts ofGiven this, I think you could also create "good until" tokens, too, now that I think about it. Maybe re-invent the web site mailto with a token that's got some way of seeing when it was generated and can only be used for, say, 24 hours after generation. That'd solve most of the problems we see with role accounts without forcing everyone through c/r stuff.
things I'd like to see hit.
exactly. At this point, I'll take a system where I can put a role account on a web page, and know ten years from now it won't be getting spam unless the spammer is grabbing the account right now. That solves 90% or more of the problems with role accounts (and other accounts stuck on web pages) we see. And it means the spammers are going to have to work harder to hide. If every email on a page has a unique token generated for every page scrape, it's not much more work to track when it was scraped, where it was scraped from, and that makes the spammer that much more visible and exposed, with very little window to wiggle in, grab and find a new hole to hide in.Spammers would have to scrape and spam in real time, which is still possible, but a lot harder.Frankly I don't think its possible to build a system which can prevent spam which doesn't also prevent valid/desirable communication. There's a scale. You get to pick a point on the scale with its associated tradeoffs.
If spammers need to do near-realtime scrap and send, I have little doubtbut it gives us new tools to fight that, too, because then we can start tracking and blocking the scraping as well.
they will,