Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Arantor
3871
Archived fixes / Re: Undefined index, Subs.php
« on April 6th, 2012, 03:33 AM »
Should we actually get on and remove create_button? It's only used in a handful of templates now and transferring everything to really call template_create_button would be better (especially if we take the time to clean up the structure and move them into $context, built in the relevant source, so that they can be cleanly extended by hooks)
3872
Off-topic / Re: Another reason to dislike reCaptcha
« on April 6th, 2012, 01:59 AM »
No, no it doesn't, that's precisely the point.
The SMF one has been broken by bots for years. ReCaptcha has also been broken for at least a year. It's incredibly easy to automate - I've even seen JavaScript implementations for OCRing the text in a CAPTCHA and even limited neural network solutions (i.e. a JavaScript routine that's able to learn and improve its ability to process text)
Please understand, we know what CAPTCHAs can and can't do, we've been fighting spam with them for years, and we've learned their limitations only too well - which is why almost two years ago I implemented my own from scratch, which Wedge inherited.
CAPTCHAs are outdated and do not actively solve the spam problem.
Limiting the website link to 10+ posts doesn't really solve the problem either, the bots won't notice and will try it anyway, the human spammers might be discouraged. We have also made that entirely possible in Wedge, to limit website and signature to higher post counts, plus it's also possible to set things up where a user can put their signature in but it isn't visible until they made 10 posts (or whatever setting you want)
The SMF one has been broken by bots for years. ReCaptcha has also been broken for at least a year. It's incredibly easy to automate - I've even seen JavaScript implementations for OCRing the text in a CAPTCHA and even limited neural network solutions (i.e. a JavaScript routine that's able to learn and improve its ability to process text)
Please understand, we know what CAPTCHAs can and can't do, we've been fighting spam with them for years, and we've learned their limitations only too well - which is why almost two years ago I implemented my own from scratch, which Wedge inherited.
CAPTCHAs are outdated and do not actively solve the spam problem.
Limiting the website link to 10+ posts doesn't really solve the problem either, the bots won't notice and will try it anyway, the human spammers might be discouraged. We have also made that entirely possible in Wedge, to limit website and signature to higher post counts, plus it's also possible to set things up where a user can put their signature in but it isn't visible until they made 10 posts (or whatever setting you want)
3873
Archived fixes / Re: Preparsing adds url bbc where it shouldn't
« on April 6th, 2012, 01:51 AM »
It's even adding it inside nobbc codes, prior to the nobbc itself being processed. Since nobbc is almost the first operation in preparsecode, that would imply the problem with this actually occurs prior to preparsecode, which implies a bug in the auto embedder.
3874
Archived fixes / Re: Split topic appears to trip Bad Behaviour
« on April 6th, 2012, 01:48 AM »
Now I have a log viewer, it might be worth emptying $settings['allow_external_forms'] now and trying it again. The test code looks like it should work since the Host should be solely the domain, e.g. wedge.org, and matched against the contents of Referer, which should be [url]http://wedge.org/...[/url]
3875
Archived fixes / Re: Changing password in profile > account settings
« on April 6th, 2012, 01:39 AM »
Fixed in r1540, moving to fixed.
3876
Features / Re: New revs
« on April 6th, 2012, 01:39 AM »
(2 files, 2KB)
Revision: 1540
Author: arantor
Date: 06 April 2012 00:38:49
Message:
! If the user's password is too short when changing it from the profile area, do actually insert the minimum number of characters into the error. (Profile-Modify.php)
! Various IPv6 related fixes in the IP tracking area of the user profile. (Profile-View.php)
----
Modified : /trunk/Sources/Profile-Modify.php
Modified : /trunk/Sources/Profile-View.php
Revision: 1540
Author: arantor
Date: 06 April 2012 00:38:49
Message:
! If the user's password is too short when changing it from the profile area, do actually insert the minimum number of characters into the error. (Profile-Modify.php)
! Various IPv6 related fixes in the IP tracking area of the user profile. (Profile-View.php)
----
Modified : /trunk/Sources/Profile-Modify.php
Modified : /trunk/Sources/Profile-View.php
3877
Archived fixes / Re: Changing password in profile > account settings
« on April 5th, 2012, 11:28 PM »
I've fixed this and will commit it in my next commit.
3878
The Pub / Re: The Cookie Law (in the UK at least)
« on April 5th, 2012, 11:02 PM »
No, but users can be reported to the ICO for non-compliance.
As I understand it, this actually potentially runs deeper than CNIL, and to be honest, the ICO is essentially brain-dead when it comes to technology and understanding how it is actually applicable.
As I understand it, this actually potentially runs deeper than CNIL, and to be honest, the ICO is essentially brain-dead when it comes to technology and understanding how it is actually applicable.
3879
The Pub / Re: The Cookie Law (in the UK at least)
« on April 5th, 2012, 10:08 PM »
That's a very, very good question. And, of course, one our government has no real answer for - like all the laws made by lawmakers who have no clue whatsoever how the internet actually works.
I think we're supposed to take it as read that as the site operator is based in the EU, EU laws re privacy would actually apply.
I think we're supposed to take it as read that as the site operator is based in the EU, EU laws re privacy would actually apply.
3880
The Pub / Re: The Cookie Law (in the UK at least)
« on April 5th, 2012, 08:46 PM »
That would circumvent the 'cookie' aspect of the law, much as pushing the session id into the URL would do so. (And in fact, I have the ominous feeling that's exactly what Google Analytics will do!)
But it doesn't solve the fact that you still have to supply the session id on each request so all you end up doing is having JS pull the session id out of localStorage and serve it up into requests.
But it doesn't solve the fact that you still have to supply the session id on each request so all you end up doing is having JS pull the session id out of localStorage and serve it up into requests.
3881
Off-topic / Re: Another reason to dislike reCaptcha
« on April 5th, 2012, 07:45 PM »
That's part of the problem, it's been billed as a 'magic bullet' back from its Carnegie Mellon days, back when it actually was pretty much a magic bullet. Now, of course, it's long since been beaten.Quote If you mean putting both the instructions and puzzle in the image, surely that will be even worse for usability than just having the puzzle in an image? (Note that bots were breaking reCaptcha by its audio puzzle for a while because that was easier!)Quote That's nothing new, especially given the CAPTCHA-solving farms. This is partly why I made animated CAPTCHAs, so that CAPTCHA farms would take a little longer to beat them.
But a CAPTCHA is not really a solution and hasn't been for a while; it's a simple automated defence - but a proper defence does involve better things like having Q&A.
However on a second note, how about a captcha question system. The question and instructions will be generated like a captcha, so the bot will have to decipher the question and answer it too, lol.
IMHO though, most bots I have seen get through most security lately are not bots but people. They create a account and get it unlocked for the bots to use it later. You can captcha the post maybe, allot of junk though just to keep a few bots out.
But a CAPTCHA is not really a solution and hasn't been for a while; it's a simple automated defence - but a proper defence does involve better things like having Q&A.
3882
The Pub / The Cookie Law (in the UK at least)
« on April 5th, 2012, 06:55 PM »
http://www.theregister.co.uk/2012/04/05/eprivacy_directive_web_analytics/
For those who haven't been following it, essentially this is about cookies and that cookies not being used for 'essential functionality' need to be obtaining permission from the user first.
I'm not quite sure how the hell they intend this to be enforced, but the fact is that site operators in the UK do need to bear this in mind, and any European operator should at least be mindful since it is planned to be rolled out across the EU in some fashion.
Interestingly this was raised some time ago on sm.org, about whether SMF would consider it and I was less than enthused at the response there (since it is a valid matter of concern, just not for them, of course)
The question for us is whether the cookie in Wedge is considered an essential function or not. I'm ignoring the fact that we could just ignore cookies and push the SID via the URL of course, which would be an incredibly bad move, and as far as I'm concerned, I can satisfactorily argue the use of cookies for members as essential functionality - for the security aspect alone.
For guests the matter is a lot more complicated. The cookie there is still the session identifier, but for guests the purpose is merely to indicate uniqueness of session, as a vague form of analytics to figure out how many users are currently on the site (as entirely unique sessions will not do this)
I find the whole concept a bit ridiculous, actually, because as I said you could ignore cookies entirely and still pass all the data between pages internally - but it does essentially exclude Google Analytics, which is of course the point.
This last point does bother me, actually. Firstly, I don't know how it's going to work if I make a plugin of GA, because I don't think it will really pass their rules, and that I'm subject to these rules. Secondly, I have the uncomfortable feeling we're going to start seeing sites that actively demand GA to be running to work, or that they'll run their own full-on analytics.
For those who haven't been following it, essentially this is about cookies and that cookies not being used for 'essential functionality' need to be obtaining permission from the user first.
I'm not quite sure how the hell they intend this to be enforced, but the fact is that site operators in the UK do need to bear this in mind, and any European operator should at least be mindful since it is planned to be rolled out across the EU in some fashion.
Interestingly this was raised some time ago on sm.org, about whether SMF would consider it and I was less than enthused at the response there (since it is a valid matter of concern, just not for them, of course)
The question for us is whether the cookie in Wedge is considered an essential function or not. I'm ignoring the fact that we could just ignore cookies and push the SID via the URL of course, which would be an incredibly bad move, and as far as I'm concerned, I can satisfactorily argue the use of cookies for members as essential functionality - for the security aspect alone.
For guests the matter is a lot more complicated. The cookie there is still the session identifier, but for guests the purpose is merely to indicate uniqueness of session, as a vague form of analytics to figure out how many users are currently on the site (as entirely unique sessions will not do this)
I find the whole concept a bit ridiculous, actually, because as I said you could ignore cookies entirely and still pass all the data between pages internally - but it does essentially exclude Google Analytics, which is of course the point.
This last point does bother me, actually. Firstly, I don't know how it's going to work if I make a plugin of GA, because I don't think it will really pass their rules, and that I'm subject to these rules. Secondly, I have the uncomfortable feeling we're going to start seeing sites that actively demand GA to be running to work, or that they'll run their own full-on analytics.
3883
Features / Re: timeformat annoys me...
« on April 5th, 2012, 05:06 PM »
And that's the thing, date() doesn't take locale settings into account, meaning it will only support English, it won't support any other language - something that strftime does do... as you mentioned.
I see what you mean about the helper function but that's really not helpful in performance terms - timeformat is called at least once every page, and for many pages it's called 20+ times, and adding that helper function is going to make it slower.
I see what you mean about the helper function but that's really not helpful in performance terms - timeformat is called at least once every page, and for many pages it's called 20+ times, and adding that helper function is going to make it slower.
3884
Features / Re: timeformat annoys me...
« on April 5th, 2012, 04:12 PM »
Sure it would be two spaces, because if you have say March 5, you'd get March(normal space that would be there anyway)(space that would be left from %e)5.
Yes, what you're proposing should do the trick, though I'm not sure about speed necessarily :/
Yes, what you're proposing should do the trick, though I'm not sure about speed necessarily :/
3885
Features / Re: timeformat annoys me...
« on April 5th, 2012, 03:41 PM »My goal was initially to fix %e to return no padding. However, I don't really care that %e returns an extra space when HTML will deal with it. It's not a big deal... So, in the meantime I figured I should just call ltrim() on the final string (" 2 Décembre"). Do you understand what I mean...?
In any case, typically in America they write the date as Month Day, Year, so you get two spaces into the mix.
There is no magic st/nd/rd in PHP AFAIK.