I actually got a job for deleting code. I was fixing a problem on a contract and noticed that I could fix the problem by getting rid of the section that contained the problem. The functionality could be provided in a much simpler way. Later the company created a position and I was given first refusal before they interviewed anyone.
It was a 8 bit embedded application in something like 10k of code. When I left I generated a short and clear explanation of why what I had done was awesome in terms of their future business ... because that is what you have to do if you work contracts. Which is the real message of the article. You have to write things up.
The unfortunate fact about E2EE messaging is that it is hard to do. Even if you do have reproducible builds, the user is likely to make some critical mistake. What proportion of, say, Signal users actually compare any "safety numbers" for example? There is no reason to worry about software integrity if the system is already insecure due to poor usability.
Sure, we should all be doing PGP on Tails with verified key fingerprints. But how many people can actually do that?
The world already know this. Having an agreement with the USA is a lot like having an agreement with Darth Vader. The terms of the deal can be altered unexpectedly at any time.
That doesn't mean that such agreements are worthless. They can still be of value to the counties making them. It is just that those countries have to take into account the unreliability of the entity they are making the deal with. Deals with the USA involve a lot of forecasting.
>This bill applies to all "operating system providers", ...
Not really.
>...for the purpose of providing a signal regarding the user’s age bracket to applications available in a covered application store.
So the OS has to provide an age signal to apps from a "covered application store" defined as:
e) (1) “Covered application store” means a publicly available internet website, software application, online service, or platform that distributes and facilitates the download of applications from third-party developers to users of a computer, a mobile device, or any other general purpose computing that can access a covered application store or can download an application.
(2) “Covered application store” does not mean an online service or platform that distributes extensions, plug-ins, add-ons, or other software applications that run exclusively within a separate host application.
It doesn't say "only if there's a covered application store present on the system". But maybe everyone in power will interpret this non-logically in exactly the right way that this doesn't become abusive.
Wouldn’t that classification apply to Linux package managers as well?
They are publicly available online services that distribute and facilitate the download of applications from third party developers to users of a general purpose computing device.
That may not be the intent, but it seems like it would still apply. Many of the “app stores” on Linux are just front ends for the package manager in some way.
I assume the people behind this don’t know things like apt or dnf exist, so it likely wasn’t considered.
There are a large number of things that the people behind this don't know about. That doesn't mean that they screwed up. It means that the law does not apply to those things.
AES defines a block cipher (128 bits in, 128 bits out) so there is no "before". I think that you are suggesting that default crypto libraries should work at a higher level where the documentation specifies that the resultant encrypted material is going to be, say, one IV length longer than the unencrypted material. ... which is valid I think... Part of the problem here is that the library is doing some stuff, but perhaps not enough. The function has a name that is in one sense too descriptive and in another sense not descriptive enough. The user doesn't know exactly what sort of thing they are getting.
Sorry, calling that a block limit was an error by omission on my part. 2^32 yields a 50% chance of reuse. If we pick a sane security margin it's a lot smaller. Assuming I did the math correctly just now, 2^-32 only gives you ~2^17 blocks; dropping that to 2^-24 yields ~2^21 blocks.
Off the top of my head, NIST was suggesting something like 8GB as the working limit. It would depend on your risk tolerance and the application in practice I guess. For something like video you might not really care about exposing a few 8 byte blocks here and there where the exposure is one block XORed with the other.
An aside, personally I quite like TDES for the purpose of generating secure handles and the like. The larger block sizes of pretty much every other common algorithm yield URLs and integers that are more difficult to work with. 64 bits is a manageable enough length and you don't have to implement the algorithm yourself (at which point you'd have rolled your own crypto).
If you are not typing in a passphrase or plugging in a device containing a key to unlock your disk then the secret exists somewhere else. Chances are that secret is available to others. The root issue here is that the user is not being made clearly aware of where the secret is stored and what third party(s) have access to it or reasonably might be able to get access to it.
These sorts of things should be very unsurprising to the people who depend on them...
It was a 8 bit embedded application in something like 10k of code. When I left I generated a short and clear explanation of why what I had done was awesome in terms of their future business ... because that is what you have to do if you work contracts. Which is the real message of the article. You have to write things up.
reply