> I bet you could even make it yourself in a weekend

This is it: the peak Hacker News comment.

From this Deliveroo engineering blog post:

https://deliveroo.engineering/2017/09/05/improving-password-...

"Therefore, from today, we will be informing our customers when we determine that the password which they use for Deliveroo is publicly known in some way. We will contact the impacted customers to request that they change their password, and advise that they also change that password at other sites where it is also used."

Thanks for posting this - I hadn't realised they were already doing it. I'm not sure how else they could be combatting password reuse attacks, short of forcing every user to reset their password.

It sounds like their engineering time might be better spent on fraud detection algorithms.

Any reason you're not supporting the iPhone 5 or 5C? Is there something you need which they don't support?

The 5 and 5C do not have 64 bit processors, which is a requirement for Content Blockers.

Content blockers seem to work on 32-bit devices if you compile for them:

"Yes, but I'd guess it's an arbitrary limitation—at least it seems to be for A6 devices. BlockParty works perfectly on my iPhone 5C and apparently on @wadetregaskis' iPhone 5, both of which are 32 bit A6 (and not officially supported). I get all the relevant menus, and it does block ads (even the huge easylist conversion works, albeit poorly)." [1]

1: https://github.com/krishkumar/BlockParty/issues/9#issuecomme...

Apple chose not support 32 bit devices in their blocking API, which isn't too unreasonable. I imagine it kept the code quite a bit cleaner (or avoided having to run parallel implementations to get good speed).

As the parent says, the API works fine as is, today, on 32-bit devices - you're just not allowed to submit code to the App Store that takes advantage of this. There is no JIT or anything else inherently architecture specific in the WebKit content blocker implementation. Thus the restriction comes either from a semi-arbitrary determination of the speed of Apple's first 64-bit processor, and/or the amount of RAM that came with it, as the boundary below which content blockers might cause unacceptable performance regression (despite their /improving/ performance on many sites)... or from some odd marketing plan to sell newer devices. Hard to say which.

Personally, I doubt it's a marketing thing. Apple do sometimes restrict software features to specific devices (Siri when it launched originally), but this is rather oddly processor-dependant. So I assume it's a performance thing.

the moon isn't actively altering its surface and orbital pattern to prevent you from landing there

Saturn V rocket is not yet required for content blockers.

Modern designer and UI experts demand better--really worse--UI than the moon lander had[0]. This can make almost any project harder than landing on the moon.

[0] https://www.youtube.com/watch?v=Qj2IETkScWA

The moon doesn't generate as much money as ads.

iOS content blockers don't support 32bit CPUs, apparently for performance reasons. This is an Apple decision, not a Mozilla decision (all other iOS content blockers face the same limitation)

Not sure why you're being downvoted. I actually had the same question, and found out by seeing the responses to your question that 64 bit is required.

Just so you know your responsive design is covering the request invite submit button when your browser goes somewhere below around 900px wide (Using chrome latest dev build).

Thanks :) It seems we have some fine tuning to do.

I am not saying I agree of disagree with the use of the law in this case but the problem that is associated with children having cameras at school could be fear of things like this: http://www.msnbc.msn.com/id/29017808/

Pardon, why does not having the camera at school help here? If they want to they can take the photos at home. In fact, I doubt many such photos would be taken at school even without a camera ban, why risk someone walking in on you?

So ban that, instead of cameras at school.

I've had a lot of experience with schools banning a dependency of something rather than the thing itself, allegedly because they feel that gives them more time to prevent it. If they can take a camera away before students start sexting, then the student never will have started sexting. If they wait until the student starts, then it actually happened.

Of course, that means also banning all the legitimate uses of cameras, implying that the school thinks students' primary use of cameras is sexting, which I find obscenely offensive.

From wikipedia [http://en.wikipedia.org/wiki/Photography_and_the_law]:

"In general under the law of the United Kingdom one cannot prevent photography of private property from a public place, and in general the right to take photographs on private land upon which permission has been obtained is similarly unrestricted. However landowners are permitted to impose any conditions they wish upon entry to a property, such as forbidding or restricting photography."

I think the council would argue that they are enforcing the ban of photography to protect the children from people who might want photographs of the children. I know when I used to work with children we had to get written consents from parents before any child could apear in a photo and in some cases we were instructed to make sure some children were never photographed and step in the way if we saw anyone with a camera.

It's not really to protect the children, it's to protect the Council from being sued by over-protective parents.

That said letting the kids loose with cameras is going to be quite disruptive.

Unfortunately money isn't the thing holding back UK 4G adoption. You can read more about the delays here: http://www.bbc.co.uk/news/technology-17853286

But even then because no two countries will be using the same spectrum my understanding is that UK 4G will be incompatible with US 4G.

The reason I would advocate using hyphens is you should do what the language (standard libraries) do. For example:

    css:
    margin-left, border-bottom (hyphenate)

    javascript:
    getElementById, documentNode (lower camel case)

    ruby:
    each_index, has_key? (underscore)

This would be an interesting discussion. I prefer to use the same coding style for the whole project without caring how the original authors of each language did it. I do however understand that the language API follows the original convention so one would eventually break it by following by reasoning. Ex in js: make_element_slide(getElementById('box')).

Once it finishes loading it completely breaks my browsers back button.

Exactly, I just noticed that in terror :) Am working on it... Has to do with the way Backbone.js handles pushState I think,, and the way I handle Backbone's router thingy.

I put up a fix. Does it work now?

For people who prefer code to do the talking you can find the EasyXDM repo here: https://github.com/oyvindkinsey/easyXDM