asuffield

> What do you know that they don’t?

I know that a law has been proposed which would effectively make them illegal.

> Despite this, others seem to be using warrant canaries.

I believe that the source of your confusion is that we are presently discussing a proposed law which may come into effect in the future, while you are examining the past when that law was not in effect.

You weren't compelled to set up a warrant canary in the first place, so I'm not sure why this is relevant. You did it to yourself.

Why do you expect a court to experience sympathy about the fact that you set out to break the law (by communicating this information that you are forbidden to communicate) and set yourself up so that you have to choose between making a false statement or going to jail?

We do not routinely release information about what happens to bugs, so you should not expect a response. I've certainly seen bugs reported on these channels be fixed. I cannot release any statistics.

> Looking at Android (OS) issues - https://code.google.com/p/android/issues/list?can=2&q=&sort=.... - it's clear that the majority of bugs are ignored.

A quick glance at that page appears to disprove this claim. If you flip it to display "all issues", there are 206689 bugs in that tracker at the moment, of which 44583 are open. That tells you that 79% of all bugs filed have been closed - so, at least 79% of bugs were not ignored.

Note that this tracker is for the operating system only, and does not include any of the Google apps that the feedback system covers.

(Tedious disclaimer: not speaking for anybody else, my opinion only, etc. I'm an SRE at Google.)

> It's a pity there's no way to report bugs like this to Google.

This is a popular myth.

General instructions are here: https://www.google.com/tools/feedback/intl/en/

In this particular case, it's an android app, so what you do is tap on the hamburger menu, hit "help and feedback", then "send feedback".

> Do the same for all countries.

So here's the specific reason why this is difficult in the case under discussion:

The EU runs as a "single market". It is intended to function such that you do business "in the EU" rather than "individually in every country that is part of the EU". There are no tariffs on moving goods between countries in the EU. Having imported something into the EU, you don't then have to pay more tax to sell it in a different EU country.

Except... the tax rates are not fixed across all EU countries. That was a bridge too far for the politicians when this was being set up. So under the rules as written, it's entirely legitimate - and intentional - to pick which EU country you want to operate in and pay your taxes there. This worked fine until some EU countries realised that they could compete against the other ones to offer more favourable tax regimes and attract businesses to themselves.

This isn't really a fight between companies and governments. The companies are the ball being played. This is a fight between governments over who gets to collect how much of the tax (to call it Germany versus Ireland would be unfair but not entirely imprecise). I do not see a way for it to be settled other than agreeing on tax rates being set by the EU, but that is politically challenging at the moment.

> Tim Cook and Apple have an opportunity and moral responsibility to help close these tax loopholes

I strongly disagree. I do not think that US corporations should be trying to settle arguments between EU governments. That is a level of political involvement which seems grossly inappropriate.

You have the intent to pass on the information and performed the act to pass on the information. That's mens rea and actus reus covered. It doesn't matter how convoluted you make the method. No court in the world is going to be amused at the idea that you can wriggle out of following the law by doing things in a complicated way.

The proposed law as written does not care how you implement it. The proposed crime is to pass the information on by any means. If you invented a way to make this really hard for yourself, that would be your own problem.

I was actually thinking that this proposed law is precisely how you "solve" the warrant canary "problem". No need to order anybody to make false statements - but if you take the canary down, you've broken the law, and you created this problem for yourself.

I think the lesson to learn from this is to be wary of anybody who says they can look at a system for organising people that works well and write down a recipe for how to reproduce the essential elements of that system. Even if they were partially responsible for creating it. Most likely, nobody understands why it works in enough detail to write down precisely what it would take to reproduce it.

(Tedious disclaimer: not speaking for anybody else, my opinion only, etc. I'm an SRE at Google.)

> But doesn't Google tries to avoid GPL?

No.

> I think they're pretty anti-GPL with Android, and have some rules against inclusion of GPLed components there, besides the kernel.

OEMs don't want their hardware support to be GPL-encumbered. See https://source.android.com/source/licenses.html

> Furthermore, are 11-hour shifts really by the book?

Yes. https://en.wikipedia.org/wiki/Working_Time_Directive is the relevant set of rules. The key one is "there must daily rest of 11 consecutive hours per 24-hour period", which an 11-hour shift complies with.

> Does the book say three of those hours have to be paid overtime?

No. They're just paid time like any other shift.

(Before somebody jumps up to wave their hands about opting out of the working time directive: as noted on that page, there is only one rule that you can opt out of, and that's the rule about a 48-hour maximum working week. There is no opt out for any of the other rules.)

Most libraries that I've used have logged every book that I accessed. It's how they detect (and thereby prevent) damage.

To state this more precisely than the others did:

Most companies are motivated to return a profit because that's what their shareholders want, and the continued employment of their directors depends on keeping the shareholders happy. The BBC doesn't have shareholders, it has a government oversight committee. The continued employment of their directors depends on keeping that committee happy, which a move like you propose would certainly not achieve.

They have an ordained purpose of providing quality content to UK citizens. Selling content internationally is only done insofar as it furthers this purpose (by generating extra funding for it). Their performance is measured based on how well they satisfy the UK market.

It's a lot for wifi, but not that much of the internet. Less than 1 NIC ;)

So it just boils down to TPM-protected encrypted storage? That obviously works (because it's how a bunch of devices work today), but it's a lot less exciting... if you can set up a full TPM stack for sealed storage (which we don't have on consumer linux today :( ) then I don't see what attacks this "stateless laptop" defends you against that the TPM doesn't already handle.

I haven't looked at this explicitly, but I would expect that if you sign in to chrome then it will follow your account preferences for which locality to use. Does that not work?

I'm fascinated by the idea of having a TPM without any on-board storage for it to use. How do you propose that would work?

If you're willing to accept stateful storage for the TPM then I agree this is straightforward, but then I don't think the "stateless device" has been achieved. If you're willing to trust the TPM's storage then you could have just used that to establish trust for everything (which is the status quo on chromebooks).

I mean tapping the external SPI connection at that point. You can't encrypt the first stage that gets loaded into the CPU, so you would simply replace that with your rootkit and then continue as normal until the user types the decryption key into the now-compromised device.

I don't think soldering's really required. If I was attacking the proposed system, I'd just jam a variation on those nifty miniature usb keyloggers into the path of the usb port itself. If somebody was building devices like this, then somebody else would quickly create such a device that could be quickly slipped into place (possibly even one you could just jam into the usb port without opening the case, like the fake slots that ATM hacks use).

(Or rootkit the "trusted" usb stick)

You are reading this correctly. The "for teaching physics" title is clickbait, which does not appear to be reflected in the body of the article. Baha'i is a religion, and he was imprisoned for apostasy from Islam in a country where that is considered a crime.

Relevant information is here: https://en.wikipedia.org/wiki/Bah%C3%A1%27%C3%AD_Faith#Perse...

It's pretty ugly.

To answer the GP's question: if you are in Iran, you are likely to end up in prison for any form of openly displaying an unwillingness to follow Islamic rules. If you should find yourself in Iran, my best advice is to leave at the earliest opportunity.

It's an interesting idea, but probably hopeless: all this does is move the goalposts. You're still fundamentally trusting the hardware to read and obey the instructions on your weird "external SPI" device, and if you're willing to trust the hardware then you might as well just put it on the motherboard like today's devices do. If you don't trust your hardware (and I challenge anybody to prove that a motherboard full of chips hasn't had a chunk of flash memory added to it without your knowledge) then you have no reason to think that the code it loaded was the code stored on your "trusted stick".

I don't believe that it is possible to build a secure system which isn't based on trusting the device that you hold in your hands. At some level, you need to have a device which is capable of both UI and computation functions to a sufficient extent to validate whatever transaction you are attempting to sign. You could push that onto a smaller device than your laptop (we already know that phone-sized devices are viable), but you still have to end up at the thing you interact with for signing purposes being a device that you trust.

According to the article, he's coming under legal pressure from various sides who want to stop people from doing this sort of thing. That sounds like an excellent time to shift gears to me.

This site presented me with five lines of text and a button that grants this site permission to read all my email.

How about no?

Any or all of the above. If you find yourself making the statement "we couldn't fix your bug because the developer was on leave for six months" then there is something mind-bendingly wrong with your world. Six months is enough time to hire another developer to fix the bug (even if it's a temp because they're coming back). You don't just... leave it broken for six months.

Well, apparently you do.

"the [...] developer needed to make the change had been on leave between February and September"

Wow. Just wow.

(Tedious disclaimer: not speaking for anybody else, my opinion only, etc. I'm an SRE at Google.)

The key piece that's missing here is the idea that risk is something you have to compare, and can combine in interesting ways, then trade off against costs.

There are a bunch of ways in which you can do compute, storage, and networking. You get to pick zero or more of these ways. One of them is "buy a bunch of iron and make a pile of it in your bedroom". Major risk factors here are your house burning down, you getting evicted, or there being a power cut. Another is "rent those services from an infrastructure provider". Risk factors here are much harder for you to visualise, but include things like "governments ban that company from operating in your country".

You can look at the risk of any of these options, and quantify it with an SLO, like "we intend for this compute resource to be available 99.99% of the time in a given quarter". You can then have an SLA that defines what will happen if that objective is not met, and measure how often this is complied with over time. There are lots of ways to analyse this information, but let's suppose that you can reduce it to a single number measuring how safe the resource is for your use case.

If you only look at a single option, and say "this has a safety of X", then the only thing you can get out of this effort is anxiety. This only becomes interesting when you start looking at differences between alternatives, like "the safety of servers in my bedroom is X, but the safety of buying resources on GCE is Y, so I can get this much of an improvement by spending that amount of money", or "by doing both of these things I improve my safety to Z, and I am willing to pay the additional cost of doing so". Or perhaps your position would be "this option is less safe but much cheaper and I'm willing to accept the extra risk".

The problem I have with the "fuck the cloud" article is that it doesn't do any of this. All it says is "the safety of this option is only X, you should experience anxiety". Is X higher or lower than that pile of iron in your bedroom? You still don't know.

(Realistically, unless you have the ability to build a system in your bedroom that has continental diversity for storage, N+2 of everything for hardware failure, etc, your bedroom is likely to be far less safe than the major cloud services - unless you live in a country which regularly bans American companies from doing business with you, which a sixth of the world's population does.)

I would say, based on everything that I've seen and heard, that the problems you describe here are far bigger and more important than the things which usually dominate the debate. These problems are also not specific to gender: they affect most minority groups and also other wide swathes of the population (based on personality type, lifestyle, etc).

The tech industry norms have ended up favouring a very specific type of individual, and that is the fundamental problem that we need to address in order to get the genuinely diverse workforce that I believe we need. What usually frustrates me about the "sexism" debate is that it studiously avoids addressing these issues, and drowns out most attempts to focus on them.

I've learned a variation on this theme, which is more specific:

You have some code that, for whatever reason, you think is not very good. There is a reason why you have ended up with code that is not very good.

If your action is to sit down and write it all again, you should anticipate getting a very similar result (and this has been the outcome of every "big rewrite" effort I've ever seen: they successfully reproduced all the major problems of the old system).

The reasons why this happen are probably something to do with the way you're doing development work, and not the codebase that you're stuck with. Until you learn how to address those problems, you should not anticipate a better outcome. Once you have learned how to address those problems, you are likely to be able to correct the problem without doing a "big rewrite" (most commonly by fixing them one piece at a time).

Sometimes I see people attempt a "big rewrite" after replacing all of the people, thinking that they can do a better job. The outcome of this appears to me to invariably be that the second team who tried to build the system with no real experience end up following a very similar path to the first team that did the same thing (guided by the map that the first team left them, and again reproducing all the same problems).

From these observations I draw one key conclusion: the important thing that you get from taking smaller steps is that you amplify your ability to learn from things that have already been done, and avoid repeating the mistakes that were made the last time. The smaller the step, the easier it becomes to really understand how this went wrong last time and what to do instead. Yes, the old codebase is terrible, but it still contains vitally important knowledge: how to not do that again. Neither writing new code from scratch without touching the old, nor petting the old code for years without attempting to fix it, are effective ways to extract that knowledge. The only approach I've ever really seen work is some form of "take it apart, one piece at at time, understand it, and then change it".

> I am not sure that Google gives its employees that though, at least not the latter.

I've been at Google for over a year, and I'd say that you get as much "work-life balance" as you can be bothered to make for yourself. As far as I can tell there's no penalty for choosing to do that, but not everybody does.

While I don't really believe in the "Stereotype of the Lazy Welfare Recipient" (they exist, in tiny numbers, and are likely irrelevant to economic outcomes due to being rare), I don't think this paper has proved what its title claimed. It's a great piece of research, but it is fundamentally about the situation in developing nations, which are capital-poor and, precisely as we would anticipate, infusions of capital into a capital-poor economy have a strongly positive impact.

To draw any conclusions about "welfare recipients", we would need similar data and research to be done in the wealthy nations. To the best of my knowledge, the reason why this hasn't happened is because nobody's run these experiments at sufficient scale in those nations (a few uncontrolled trials have been run, but on the scale of 10-20 people, and we need thousands). We should run that experiment and find out for sure.