anyzen

Thank you for the clarification!

Not sure if I understand this correctly, but the attacker's JS must load the pages in question to see if they are in cache, right?

Wouldn't that put also them in cache, which means that next time this technique is used it will not work? Even more, there is now plausible deniability: "I never saw these pages, I guess some JS must have been snooping around and put them to my cache..."

And the logical workaround is disabling cache, which helps fight against other tracking techniques too.

All in all, this doesn't sound so worrying. Unless I missing something?

Execute better. It depends on the idea what this means, but in general your product should be a better choice for the customer than the competitor's. You probably won't be able to achieve that for all customers, but the more you convince you are better for them, the more market share you will have.

No need to decrypt SSL, there are easier ways: https://xkcd.com/538/

These frameworks are inevitably much more generic than any in-house solution. On one side this is great, because it means that the abstractions need to be sensible - but it also means there is much more code to maintain. So yes, sometimes maintaining your own solution will be easier than maintaining an abandoned opensource solution. Of course, even better would be to use a solution which will not be abandoned.

Also note that these frameworks lock you into design & feel of their choice. This might work for some use cases and for now, but when the requirements change you often end up fighting the framework. I don't have a solution to that though. :)

I made an opposite journey. While working in C and Java I commented heavily, but in Python I prefer to just leave a comment here and there if I'm not sure the reason for the code and its intent are clear - but at the same time a comment is also a powerful signal for me to rethink that piece of code and make it more obvious.

I find both of your examples readable to about the same level; MySQL one because the naming is helpful (`number_of_bytes_read_from_buffer`) and SQLite one because of the comments - I would be lost without them. For example, why is a function that does "Release the STATIC_MASTER mutex" called "leaveMutex"? On the other hand, SQLite comments explain much more about how the code is used, what assumptions are made, so this is really a bonus.

> Why is docker better than virtualenv with a requirements.txt file?

It's not, it solves a different issue. If you only have Python as dependency, requirements.txt are fine (well, user needs to install correct version of Python, pip and virtualenv / pipenv, but that's doable). But as soon as your app is actually composed of nginx / apache, python, some background process in Rust, bash scripts for cron jobs,... then you have a problem with app delivery, which Docker solves nicely. Just package eveything in a Dockerfile and distribute the image. Bonus point: you can now test it locally, with the same installation.

I jumped on Docker wagon very early for this exact reason. I don't care about hype, but it does solve these kinds of problems.

Old timer to 2 other old timers: Docker does solve a problem, and this is quite close to it... We had a solution that we needed to install on servers for multiple clients. Before Docker, we had to make sure the libraries were correct (on CentOS, Debian, Ubuntu,... you name it), which was a nightmare. We were literally debugging on customers' installations to see why it broke there.

Docker solves this nicely. Apart from the kernel you take all dependencies with you.

In this case, it provides an easy installation of all the dependencies in a single command, while still allowing for customizations, and all in a standard way. Not to mention that certificates and similar are all solved.

Forget about hype and just try Docker. It's a tool like any other. It can be abused, sure, but it's useful too and it's here to stay.

EDIT: difference between Java and Docker is that containers depend on kernel capabilities, not on some 3rd party JAR maintainers. In my experience Docker simply works unless you are doing something really weird.

A few days ago I tried to install LibreOffice because a (legal) copy of MS Word gave me trouble and I needed a fast solution. However max. download speed I could reach was ~50k/s, bringing download time to almost an hour. Net speed test on the same computer reached full speed with no problem. Download from another (Linux) computer from the same URL was a matter of minutes. All of the mirror sites I tried had a similar speed.

I thought it was just some weird misconfiguration, but now I wonder... Could MS be actively slowing down downloads from LibreOffice to discourage users from using it?

Just to show how absurd such practice is - if Mozilla wanted to do the same, they should intercept requests for Google.com and Bing.com, advising users to use Mozilla's search engine instead. I doubt Google would keep paying them if they did that though.

And iDefense is doing something similar?

What is that about?

    - 2018-04-03 - Verified existing and sent to iDefense’s VCP
    - 2018-04-04 - Validated and acquired by iDefense

Is there a company that buys information about bugs ahead of time so they can protect their clients?

(a cursory Internet search didn't answer my question)

I have been currently exploring the option of open sourcing a project of mine and have researched CLAs a bit, but would love to be corrected if mistaken.

It is as simple - and it is not. You need to take care of special cases, like contributions from company employees in their free time (their company could still own rights to this work), people contributing other people's code (SO answers), patents and whatnot. Fortunately there are existing CLA agreements (Apache for instance).

As for this being the social issue, I don't know yet how big a problem that is. It's never bothered me before, as I recognize that maintainer might want to take the project in another direction in the future and since I don't want to maintain it, I am just happy that they are doing it for me. I will use CLA for my project and if someone doesn't like it, it's fine too - I don't mind forks (if they are well maintained, I'll just switch to them ;), and if someone doesn't want to contribute because of this, I don't want their contribution to be in my code anyway, because it limits my options in the future. There's a new post today on HN [0] that presents options pretty nicely, and it is very aligned with the conclusions I came to.

[0] https://www.influxdata.com/blog/its-time-for-the-open-source...

> In particular, I've always wondered why "GPL or ask me for permission" isn't being explored more.

Maybe because then you need to have CLA's (Contributor License Agreements)? Otherwise, who is "you" that they need to ask? It's not just your code, it is based on work of many other contributers.

> Moreover, projects do fail even with a fully experienced, fully vetted staff running the show.

Sure - but in that case they usually don't fail because of technical decisions (which is what OP was talking about). There are however many other ways a project can fail (bad management mostly).

I'm not sure if this is what you are looking for, but I have been using headless Chrome through Selenium (using nightwatch.js) for some time now and it works great. You will probably need to rewrite your tests though, but they will support FF too. YMMV.

And uMatrix! I don't know what I'd do without it.

> One might also argue that fixing it is as easy as replacing load() with safe_load(), but many people are unaware of the problem, and even if you’re aware of it, it’s one of those things that can be easy to forget. It’s pretty bad API design.

It is. At API design time, it would have been trivial to replace them with `load()` (which does the same as `load_safe()` now) and `unsafe_load()` (which does the same as `load()` now) and probably avoid this pitfall altogether. Now? Much more difficult to solve.

This. I rewrote pure-JS implementation of some topology visualization in D3 and very much regretted it. The abstractions are simply weird, documentation poor and the resulting code difficult to reason about and maintain. Useful for toy projects, but I wouldn't use it in a serious app anymore.

> I really wish there was a library out there like D3 that tried harder not to surprise me with every abstraction.

Interestingly enough, I find that the combination of React + inline SVG fill this space pretty nicely. The engine is well thought out and documented, as is SVG. And animations are easier to do with CSS anyway.

EDIT: note that React is declarative too, which helps with visualizations a lot.

Exactly. (& sorry for late reply)

Same here. The CI is easy to use and makes sense, though it lacks some features - for instance being able to automatically run manual jobs as soon as their predecessors complete. Now I have to wait (!) and then click so the manual job starts...

But all in all, good product, I hope they succeed!

Of course, JS has a problem in this regard that while it looks like a language, it is also a (de facto) assembler for the browsers. So disabling anything in JS will break lots of sites which will never be fixed.

However as far as programming is concerned, many things have been deprecated through transpilers and linters (for example "==" throws a warning in ESlint).

Not sure why you're being downvoted. Google has different business model than Apple and expecting it to care about user experience in the same way simply doesn't make sense. And yes, they mostly care about data, because that's what they're good at - collecting data, analyzing it and turning it into profit.

My point exactly... ;)

> If you want, you can build and sign your own apps and put them on your device on an iPhone.

HA! Sure. For $100 a year. And from a Mac.

> I presume you’re talking about the headphone jack, which google followed up by removing from their pixel phone 12 months later? Why does apple get the hate here and not google?

Because Pixel is not the only choice one has inside the Android ecosystem, as opposed to iOS one? Samsung, Sony and others still have the jack afaik.

I agree with you about price though. Apple is no more expensive than others (considering the quality of build).

There are always assumptions being made, no matter what you do. But "uppercase -> constant" is such a generic and cross-platform convention that it should always be followed. This code should never have passed code review for this glitch alone.

True. So, did any of the initial participants gain employment?

> ... with purely visual sensors

So maybe they shouldn't use purely visual sensors until the problem is solved? It's not like they don't have any other option.

Genuinely curious about the statistics: does it count human corrections as if they would have resulted in the crash? Because if not, they are simply not valid.

Note that it's not (only) about colors... Human vision has trouble picking out colors in the dark, yet it still allows us to process world around us to a surprising degree. However until the "brain" of the car is good enough, it is simply irresponsible of Tesla not to use all the data available, from as many different sensors as possible. Testa should use color. And they should use Lidar.