Forgive my naivety here, but is there any way to tell which sites over the last 2 years I/we have used that may require new passwords, and whether they've been fixed?

I'm kinda looking at a site that lists the major sites (Banks, Socials, Shops, etc) that shows a status on whether you're fine / should change password / await fix before change password)

Yes. All of them.

Seriously, it's easier to just change all of your passwords than to hunt down a list (that will be incomplete and give you a false sense of security), cross-match against servers you might have an account on, then change their passwords.

Just change them all and be done with it.

The "whether they've been fixed" part is a little tougher, because that lets you know when you should change your password. General sentiment I've been seeing is give it a week for everybody to fix their stuff (even this might be a little long) and then change your passwords. If a given site says either "we weren't affected, here's why" or "we've patched our stuff, we're all good" then you should change your password on that site ASAP.

When would be the optimal time to perform these password changes? I am assuming that not every affected site has been patched yet, and it would be pointless to change the password, and log in, before they have fixed the problem.

Actually, it turns out that LastPass (which I use) has incorporated most of what's discussed in this sub-thread into its security checker tool, so it automatically tells me which sites need to have passwords changed for them and when.

Use one of the testers to check if the website is currently vulnerable.

And then use your browser's certificate inspector to check the issue date of the certificate. If it's earlier than April 7, 2014, it's still insecure.

Only if they were impacted by the bug.

It's rather unreasonable to expect sites that know they were not impacted will update their certificate. So unless you want to write off your bank's website for the next year or three until the date expires & they renew it then, (banks seem to have avoided this- suddenly dawdling behind the bleeding edge doesn't look so bad!) scorched-earth policies are a bit much.

Actually I might even say the opposite; if the site is secure and the certificate is older than 4/7/2014, that suggests the site was not impacted. If the certificate is newer than 4/7/2014, that pretty much guarantees the site was impacted. It is possible the site patched openssl and did not renew the cert, but in general people are not going to do one without the other.

I can't work out why the width would be need to be 1px bigger in width? I don't see the explanation in #3. Also, the array in #3 shows a 9x9 grid of 81 values when there are only 72 pixels?

If you only have 8 samples per row, then you have 7 adjacent pairs. If you use a bit to represent the differences, you'll only have 7 bits. If you want 8 bits, you need 8 differences, so 9 samples.

That makes sense, but why does the example have a 9 by 9 grid, would it be a 9 columns but only 8 rows?

Yes, you are right, it's a mistake in the text. I'll correct it.

Does anyone else find the opening statement a little misleading? Yes they originally come from one place, but they are sent from Twitter to the app of your choosing via JSON or similar. Sure there's going to be more than one request for the icon sprite and user avatars, but all from Twitter.

"When you open the Twitter app on your smartphone and all those tweets, links, icons, photos, and videos materialize in front of you, they’re not coming from one place. They’re coming from thousands of places."

It sounds like you're misinterpreting. The way I'm reading it, by "thousands of places" they mean "thousands of machines". Which may be an exaggeration, but it should be trivially obvious that data is sharded and must be collated for display.

Wonder how this affects battery usage and temperature on the devices, I'd love to see reports based on app usage with/without mining enabled.

Did you check to see if the phone/ipad heats up while playing?

I can understand the need for lowered bandwidth, but the need for better cross-browser and cross-platform support is more important.

For example; Github README files, we can insert a GIF of a screencast, but obviously we can't run our own JS, CSS, or embed video. There is where GIFs are the only option, unless of course you want to redirect to an external site, but for small repos it's overkill.

The other issue, is saving and sharing. How many people have a folder full of GIFs? Has anyone tried saving a GIF from the polymer element? As you can imagine, it saves a frame, which makes it useless. Sure, you can add a button to Download a compiled version or the original, but why should we add custom controls when everyone knows Right Click Save As?

For me, cross platform compatibility without requiring an extra file (HTML to actually play) per GIF if more important than filesize and bandwidth. Bandwidth is obviously costly, but maybe the issue is knowing when to create a GIF and when to create a video instead, why is the issue with the playback why not emphasise on the creation size?

Basically, the 'check' to see whether you have any moves left isn't in fact whether there are moves left, it's just a simply 'if no more space for new block = game over'

The addition of the block being added no matter the move is an escape round the original (and obviously more verbose, probably why excluded) method of calculating moves remaining.

All in all, decent effort, but it's not 100% true to it's aim

If I press UP and only UP, it will have the 16's in the top row, 8's in the 2nd, 4's in the 3rd, and 2's in the 4th without fail. It then says GG 272 even though I have more moves.

Out of 3 times playing, it has some this 3 times.

Using 'ported' assumes that you gained access to the original source code for Flappy Bird, rather than just recreating Flappy Bird on C64.

Not necessarily. The word just means [trans]port to another platform. It's only relatively recently that writing automatically portable code has been possible, and even then there's usually some modification involved, otherwise we'd just call it "recompiling".

It has been used this way in relation to games for years. Game ports of the 80s and 90s very often involved complete rewrites from the arcade version, sometimes without access to even the original graphics.

I remember reading accounts of ports where the porters were not even given a spec of any sort, but were lent an arcade cabinet of the original and had to essentially test there way through everything to figure out what to implement.

I wanted to emphasise trying to stay as close as possible to the original as possible, while still being a C64 game. I didn't have access to FB source, so it's just reverse engineered. It's still in need of tweaks and fixes tho (I spent 2 days on it).

Solution wise, even if iOS devs created a fix to purge the cache older than X weeks and to recechk it would still require all your friends to install the update before it takes affect, so I don't even see a fully fixed and timely solution to this.

Shouldn't the comparison of prices be for the original cost of the game, rather than how much it costs nowadays? Surely in 14 years time the iPad version would be indeed be cheaper if still existent?