Coding in the open: how to do it securely
gdstechnology.blog.gov.uk
gdstechnology.blog.gov.uk
And importantly, when to use a deadbolt, or deadbolt + steel frame door, or a safe. All of which are well understood but can be implemented depending on when circumstances warrant. i.e. tool shed vs bank vault.
In this amusing video this guy goes over details of different locks, and explains why they are not all created equal.
Because it's certainly not a privacy problem to have every interaction between a citizen and their government reported to an overseas megacorp.
But sure, let's talk about security.
From what I know of Piwik it's run on your own servers, so the traffic doesn't go elsewhere.
I cannot claim to have worked with either one though.
Not that I necessarily agree with the original comment but that's the reasoning.
Safe harbour provisions and contractual agreements of this sort are effectively worthless when it comes to crossing borders, particularly where the US is involved.
Using adblockers to turn it off is not acceptable, and won't protect the majority of less tech-savvy folks.
If you can use Piwik for things you think must be be more secure then that tells me two things -
1. It's possible for you to use Piwik
2. You don't believe that sending sensitive data to google is always a good idea either. You just don't think that most government-citizen interactions are sufficiently sensitive for some reason.
Having said that, then isn‘t now, and I wouldn’t be surprised if a future Government as a Platform service isn’t a cross-government analytics system hosted from the UK. I just don’t see the pressing need for it, based on the assumption that Google actually are anonymising the data. If you want to disagree with that assumption then that’s a valid viewpoint too, but I see no evidence for it.
This is exactly the wrong way around. For every sensitive area, such as privacy, it is upon the company to prove proper handling of data. But if that company is outside your legislation, without any legal means in their country, how could that ever be possible?
Taking just their word is like trusting the food industry with hygienics until their customers become undeniably sick.
A better strategy is not to create sensitive datasets in the first place. In Germany, this principle is called "Datensparsamkeit", which could be translated to "data frugality".
Moreover, every country should have something like the FDA for data hygienics. Unfortunately, even in Germany where we do have "Datenschutzbeauftragte" (designees for data protection), those can make a lot of noise but don't have much power. This is still better than not having those people, though.
Google Analytics is a certainty, and reasonable alternatives are available.
I think it shows a terrible attitude from the department responsible to use GA. Not everything should be done by the lowest bidder, regardless of the costs. Maybe I'll write to my MP...
You absolutely should be taking precautions to make sure that what you're doing on AWS is secure. And in fact erring on the side of using providers who host in European countries, preferably European organisations.
(addendum - I spent a lot of the early part of this year working on AWS-based data processing systems for a large bank, they took massive precautions with the transport and storage of their data within the AWS system, including IPSec overlays, 14 day maximum node lifetimes and various other things. I realise that at some point you're trusting amazon, but there's a lot can be done to avoid having problems in the first place. "Not sending data to places you don't absolutely have to" seems pretty basic)
Maybe this particular case is an example where the principle of a lean government fails?
Preserving our users’ anonymity is one of our major priorities and we actively work to improve how we do this.
That's surely secondary to privacy and security?
>> If you want to disagree with that assumption then that’s a valid viewpoint too, but I see no evidence for it.
I see a whole litany of problems with your assumption, based on the state of the world in terms of large-scale leaks and hacks, on the laws in the US which are much weaker than our own protections, and on the actions of various US agencies when they desire access to privately held information.
I see no reason to believe that anonymisation of the date somewhere within google infrastructure is an adequate protection, whether it actually happens as contracted or not.
Look, it's clear that you don't consider this important enough to do something about. Some of us do, and some of us would rather that if you can't do this with private analytics, you don't do it at all. And if that makes delivering your service harder, slower and more expensive - so be it. What's happening here is not right.
I mean, what you're saying when you reference point 2 of your design principles, is that it's alright to throw user privacy under a bus, so long as you can deliver the software effectively. This isn't a good justification.
Actually thinking about it, the best way would be to apply for GDS’s recently opened Deputy Director of Technology and Operations role :) https://www.civilservicejobs.service.gov.uk/csr/jobs.cgi?jco...
If you don't mind another dumb question, is the benefit great enough for the hassle of complaints and the possible compromise of ostensibly private information?
There are self-hosted solutions, but I imagine they'd entail experts to interpret and implement. I wonder if they could just do A/B testing and get the same results or if they could simply do surveys? Though, I suppose those come with new faults, variables, and expenses.
Again, thanks for the answer.
The hassle of complaints and the possible compromise of "private" information (like what your browser sends) isn't that significant. The pain from complaints is trivial, largely confined to Hacker News threads of no significance whatsoever. The ostensibly private data is protected contractually and legally.
I'm not aware of any approach that both yields useful information and eliminates any possible risk of compromise. Surveys and A/B testing and self-hosted solutions all have the same problems and risks, and generally extra costs to boot.
In short, the cost-benefit analysis isn't all that different from that of a company considering an analytics tool.
Once in a while, chaos theory or traffic modeling come up. So, I get to give back. ;-)
Again, my sincere thanks.
Or, in full: "Government should only do what only government can do. If we’ve found a way of doing something that works, we should make it reusable and shareable instead of reinventing the wheel every time. This means building platforms and registers others can build upon, providing resources (like APIs) that others can use, and linking to the work of others. We should concentrate on the irreducible core."
Slightly different than the title.
Can't do privacy because the principle says "Do Less"? Why do anything?
And I'll add another thing: This contract is between a government agency's bureaucrats and a private corporation, but it affects unknown numbers of private citizens who, really, have no choice but to have dealings with their government. Claiming that contract is sufficient is laughable, even if Google didn't have every reason in the world to disregard it and simply pay the fine associated with disregarding it.
[1] https://www.judiciary.gov.uk/cookies/ [2] https://tools.google.com/dlpage/gaoptout
The problem is that a license agreement prevents nothing; it may establish consequences for an action, should it occur and should it be detected and should the consequences be enforced, but it is unable to prevent that action from occurring.
That's the difference between 'can' and 'may.' A license agreement can't prevent something; a technical measure (e.g., not using Google Analytics or using some form of privacy-preserving analytics protocol) can.
If there's anything that human history teaches us, it's that Murphy's Law (that whatever can go wrong, will) holds: if it's possible for someone to do something one would rather he not, he probably will, sooner or later.
keys and credentials
algorithms used to detect fraud
unreleased policy
In Canada, Tax Policy Changes take effect from the day the bill is introduced to Parliment or published for discussion for exactly this reason.
If you give the wrong people to the end of the year, they'll grandfather in as many as they can, even if they sit unused. So now you're putting off curbing the installed base and instead you've actually created a glut. Now your tax will have zero net effect for four or five years and will make things (say, smog) far worse in the short term.
If the people rushing to buy up the supply to simply store them off-line happen to cut off people who need them for what are sensible and essential reasons, you end up with a litany of cases of the tax causing problems paraded about as it comes into effect, and it ends up repealed or undercut because of political pressure.
(Usually 1-year window extended because "we need more time to phase it in" and by the time the second window would close, it's gutted.)
It's not just that it can end up counter productive in the short term, it's that it can undercut itself as a law as well by destabilizing a market that usually has low, but important volume.
It makes perfect sense, to me at least, for taxation regulations to be the same. Of course, they'd probably just default to calling all rule changes emergencies...
Sort of related: I love the idea of paying taxes. Mine are prepared and filed as soon as I can do so. I have a great time paying my taxes, to the point where I bring a bottle of wine and flowers to my accountant. But, man, I really hate the complexity and how the money is spent.
Anyhow, maybe they should only make rules for the first half of the year and then none of the changes go into effect until the first day of the year? I like your idea.
nearly every Budget affects duty on things like beer and petrol, and go into effect at midnight
people know to fill up their car the night before!
But as well, policy discussions that allow no privacy tend to be very circumscribed.
Filtering data to find who is breaking a law is different from the law itself and from penalizing people.
What you can't do is detect it by opaque means and then proceed to sanction people or even gather some too elevated investigative powers.
Then I discovered blockchains. Here, the software is run by the network and does nothing persistent unless a majority of the nodes agree. That makes it much harder to corrupt the persistence layer. Blockchains are NOT just for achieving global consensus about a ledger. They can be per-stream-of-data. That's the approach we take at Qbix.
There are still many other vectors of attack besides corrupting the database. However, in Web apps, the real pernicious thing is corrupting the data. Everything else has already been secured by webserver makers and language runtime designers.
PS: Finally, you can corrupt things on the client level, eg making a client sign a transaction the user didn't authorize. But at least it is localized to the corrupted clients, and not the whole network.