Wedge

I think we'd need to do performance testing on that to be sure ;)

I'm still in a place mentally where I forget such constructs because I still find myself thinking about the cross-system methodologies I've been exposed to over the years...

I do try, and I do also try not to snap at people who ask for help (but when people who ask for help then throw it back at me because they didn't get the answer they wanted, that pisses me off no end)But why do guests need to have cookies shoved at them, exactly?Pretty much the official line from SMF is that it isn't their problem. I'll come back to that when replying to markham's post, though, because there's a lot more to it than that.Depending on implementation it may not be as simple as that, or it may be. Certainly if it is functionality related, you're far more covered but as I understand the wording, you'd have to ask before setting those cookies, because it's up for debate as to whether it's 'required' functionality. A shopping site would not work very well without a cart setup, and as such a cookie there is clearly for required functionality. But for remembering preferences, as I understand it, that's not necessarily defined as 'required'.

This is part of the problem, actually, the guidance from the ICO is very vague and open to interpretation. If in doubt, seek guidance either from the ICO itself or from a separate legal institution.Well, there's nothing that says you can't allow guests. You just have to be mindful of how you approach it.

But you're exactly right, my very first thought when this was announced is that analytics cookies would be the sort of thing people would not opt-in for. Which is why I was less than thrilled at the way the ICO itself handles Google Analytics, because you can't (easily) opt in to certain cookies and not others. But I figure it will encourage a migration off Google Analytics, which from my perspective is no bad thing.The whole escapade is pretty shocking if you go back and look over the history of it - like so many recent laws, it is implemented by people who do not really understand how the internet works and is going to be abused. I personally think it's going to be withdrawn but because I just can't take the risks attached, I don't see how I can do anything other than look at it properly, as it's not just my own stuff that I have to bear in mind.

Did you know, in fact, that at one point a branch of the German government was using SMF for discussions? I don't see any reason why Wedge won't be able to appeal to that level - but it does of course require that we comply as best we are able (on a generic level) with the legislature out there, and we can take case-by-case matters separately.I'm certainly willing to implement a decent solution, even taking into account my personal reservations about the whole matter - provided that I can get some meaningful information from the ICO. The big problem - as we've seen from pretty much all the forum camps - is that people look at the wording, look at the guidance, and make what is really a prognostication about the way things should be interpreted.

I know pretty much everyone is taking the view that the session cookie is probably OK and that the main cookie issued to members is also probably OK in and of themselves, but I'm not yet satisfied that this view matches the guidance the ICO themselves issue, especially considering that they don't even allow *their* session cookie to be transmitted without this consent.[1]

And if the ICO come back to me and tell me that they're satisfied with the breakdown I've given them of SMF and Wedge cookies, so be it. But I strongly doubt it, and in fact I realised there are more cookies issued by SMF and Wedge than that, but those we can work around or build into the existing systems.Actually, one of their developers has now issued a mod that should cover the fundamentals. I haven't tried it, but a quick glance at the code suggests two things: one, it'd probably work to prevent cookies being issued and two, it doesn't quite conform, because it doesn't indicate what the cookies in use are or what they do. (Nor can I see any way for mods to register such.)And, without being funny, this is why people who are neither technically nor legally qualified to make a judgement should avoid doing so.

His view is incorrect, because the wording of all the related legislature makes it very clear that any transfer of data that is 'strictly required' to function is permitted, and in any case when a user goes to a page themselves, they are the one initiating the transaction of data, and are implicitly giving permission for the bulk of the headers going anyway. (That said, there are privacy implications relating to things like the user-agent.)It's probably true that were things different, I'd have gotten involved on an SMF modification. It's also probably true that working code would have been available sooner, though there is a work in progress available from the team at this point in time but even then it seems to be issued personally, not under the 'team' as it were.You as a site owner cannot be held accountable for that since it is not a cookie you are issuing, and it is the ISP who is clearly at fault. If you can identify which ISP it is, take the matter to the ICO as a complaint.

1.	Yes, that's one thing that hasn't exactly been noted by those who've looked around the issue.

No, you have to put up a prompt to users before cookies are used, and ask them for permission *TO* use cookies. Until you receive permission you cannot use cookies in any fashion.They're not properly complying. Go look at the ICO's website and check your cookies - note that no cookies are set until you agree to them.As has been said many times in this thread, no, you would not be covered. Providing information is not sufficient, you have to seek consent before using cookies.No, they don't. They figure you will contact the manufacturers of the software you use, i.e. us, or the SMF team or the phpBB team.

I don't think it would be any use, certainly not as a core feature. If anything I'd rather remove topic views before implementing this.

There are major performance considerations attached, namely that you'd *HAVE* to put this in its own database table otherwise the nightmare of updating the messages table (and preventing any other process even viewing threads while that update occurred, as default on MySQL prior to 5.5)[1]

Even then, you'd have to exclude search engines (which in itself is unreliable, just as it is excluded in theory from topic view counts), and even after that, the strong likelihood is that all you're going to see is a stream of increases over time, proportionate to the age of the message.

Ten messages each posted in close proximity to each other are going to have an almost horizontal (level) trend, messages further apart will get a proportionately higher spike, but that's all it'll tell you.

1.	Tables in MySQL before 5.5 are defaulted to MyISAM, where an update to the table requires table-level locking, meaning nothing else can touch the table. You can use InnoDB in 5.0/5.1 and it's default in 5.5 but that's not widespread yet.

Ignorance of the law is no excuse, and if you prepare to run a website you should generally go out and make sure you are compliant. I've done a considerable amount of legwork for this reason over the years.No, they want to make sure your privacy isn't screwed over. The real target of this law isn't to penalise site owners, it's to fuck over Google, and in particular the way Google's cookies track your actions, both their analytics and their ad cookies.

Also, read the discussions. They're not asking for huge notices. They're asking for prominent ones discussing cookies - the thing is, most sites don't really need cookies at all.

Consider this fact: SMF and Wedge, currently, use two principle cookies. One is issued to guests, whose sole purpose is to track what a guest is doing, and if you read my letter to the ICO, there are even privacy concerns about that. On the other hand, one cookie is only issued to members when they sign up, which will typically be covered by the agreement, so really all we're fighting about in Wedge's case is a cookie whose sole point is to identify a unique user. It's only really required to validate the uniqueness of the user, it's not really required for any other valid reason.It's not your problem. You only have to worry about the sites you manage. However if you find a site in the UK that issues you with cookies that don't really fall under the current laws, you can actually take them to the ICO. So yes, it is a problem if you run a site, but if you don't, it's no issue.Ignorance of the law is your problem, not the law's problem. No court of law will consider that a valid defence. As a site owner you are responsible for investigating the laws in your country/region and making sure that you continue to be informed about those rules.

In this particular case, it's been referenced many times on tech news sites, so I suspect if it were tested in court, it would be even further against you - it isn't as if this is a law that has been pushed through quietly.You wouldn't win.

I forget whether this happened in the US or UK, but a few years ago, one or other of those places introduced some legislation to ensure that shops and offices introduced suitable measures for access by disabled people. Thinking about it, it might well have been the UK when the Disability Discrimination Act came in. Anyway, this guy in a wheelchair went around place after place after place, and each place that fell foul, he took them to court. The first couple went to court but after a short amount of time he was declared a vexatious litigant (i.e. someone going to court because they're a pain in the arse, not because they necessarily have a valid complaint) and was forbidden from doing it thereafter.

Oh, I'm not afraid. I just don't want there to be any illusions about whether this is a 'security' measure or not, you know?

It is a form of anti-bot measure.

And therein lies the problem. Your code is passive, it's doing lookups to see if there's something new. So if you want it to appear with no more than 10 minutes delay, that's the maximum caching time. But then your server does much, much more work in doing lookups to figure out if there's something new.

If you don't like these options, you have to figure out something different, namely something such that when you perform an upload, you somehow notify your other site.*shrug* I doubt there's much in it.

So you're fetching tags from Instagram... how often are items posted from Instagram that fit your tags?

If they're posted every 5 minutes or so, 3-4 minutes (180-240 seconds) is fine, if they're posted every 10 minutes, 8 minutes of cache is fine.