Encryption is a necessity(blog.mozilla.org)
blog.mozilla.org
Encryption is a necessity
https://blog.mozilla.org/blog/2016/02/16/help-us-spread-the-word-encryption-matters/
7 comments
I agree...and with services like Keybase.io it's getting easier to use.
[EDIT: Thanks, I have one now :)]. Does anyone has an invite for Keybase by the way ? I've signed-up a while ago but the queue is probably to long. It seems a really promising service.
On my case, I've just migrated my domains to use letsencrypt, even if it's just in beta, it's so so much easier compared to 100% manual previous solutions ! Even if it's not domains with a huge trafic, I feel I'm doing my part to help !
On my case, I've just migrated my domains to use letsencrypt, even if it's just in beta, it's so so much easier compared to 100% manual previous solutions ! Even if it's not domains with a huge trafic, I feel I'm doing my part to help !
Sure, I just sent you one to the email address on your profile.
You don't have another do you?
I've been waiting for my invite for over a year now. :-/
Sorry I just saw your reply. Glad you got one.
I still have a bunch more, if anyone else wants them.
I still have a bunch more, if anyone else wants them.
If it's not too late and you still have some, any chance you can send me one? would appreciate it!
I tried but looks like someone else already sent you one.
P.S. Great looking Hakyll site!
P.S. Great looking Hakyll site!
I was invited many months ago but I messed up the username. After investigating I realized that there's no way to fix it, and keybase staff says the only way is to delete the account and get re-invited [1].
I forgot to delete the account, but I did so now, so if you're still willing and would be so kind as to try again, I would greatly appreciate it! If not, no problem!
Thanks for the compliment!
[1]: https://github.com/keybase/keybase-issues/issues/803
I forgot to delete the account, but I did so now, so if you're still willing and would be so kind as to try again, I would greatly appreciate it! If not, no problem!
Thanks for the compliment!
[1]: https://github.com/keybase/keybase-issues/issues/803
I tried again as you said, but it still complained. What I ended up doing was to send the invitation to your gmail address without the two dots (as it's an alias for your original address), and apparently it worked.
I also emailed you the invitation code they generated, from my personal email.
I also emailed you the invitation code they generated, from my personal email.
Received! Thank you very much!!
I could definitely use one.
Thanks in any case!
Thanks in any case!
I just sent one to the address on your profile
Any more?? I haven't been waiting a year - but I've been waiting eagerly if anyone has any!
Done.
[deleted]
Well, why not massively fund Thunderbird with a focus on usability and end-to-end encryption then? :-( Or maybe invest in Signal to they can finally start to fix and improve at a remotely competitive pace?
Thunderbird works pretty well with S/MIME to encrypt/decrypt emails. It does not work as well as Mail.app on iOS/OSX, but it works.
it's
A) Not transparent
and
B) No longer supported by mozilla.[0]
[0] - http://www.zdnet.com/article/mozilla-scraps-thunderbird-deve...!
A) Not transparent
and
B) No longer supported by mozilla.[0]
[0] - http://www.zdnet.com/article/mozilla-scraps-thunderbird-deve...!
Why isn't it transparent? Isn't the code open source?
Not transparent to the user. Good security is one you don't have to have a PhD to configure. How much encryption is in iMessage? (Lots) how much did you do to configure it (none)
Transparent encryption (or, encryption for everyone even my mother) is the best way for it to be effective. So when I say transparent. I mean it should not be obvious to the end user and that user should not have to spend significant time configuring it.
Transparent encryption (or, encryption for everyone even my mother) is the best way for it to be effective. So when I say transparent. I mean it should not be obvious to the end user and that user should not have to spend significant time configuring it.
At the end of the day, we need a way to handle key management for asymmetric encryption like pgp.
How do we allow people to share their private keys across multiple devices?
How do we allow people to share their private keys across multiple devices?
Your comment about Signal threw off some thoughts :)
I've said before that I think Signal's UX is not great esp compared with other messaging apps.
The following just came to me so I'm going to digress for a bit into stream of consciousness.
* Signal allows for calling now so why not require a first call to verify the other party. I would think people are pretty good at recognizing voices.
* Or send an image and video call to verify?
Still looking for a Signal+Ricochet+Burner type app...
I've said before that I think Signal's UX is not great esp compared with other messaging apps.
The following just came to me so I'm going to digress for a bit into stream of consciousness.
* Signal allows for calling now so why not require a first call to verify the other party. I would think people are pretty good at recognizing voices.
* Or send an image and video call to verify?
Still looking for a Signal+Ricochet+Burner type app...
I find the signal user interface just great. No really, it's fine. Just use it and recommend it to your friends and contacts.
Full disclosure, I have no association whatsoever with signal, it's just good.
Full disclosure, I have no association whatsoever with signal, it's just good.
For example, I hate how the contacts list works. It doesn't show all my contacts, just some. Took me forever to figure out the ones in bold actually have Signal installed. Also, not intuitive that clicking on the name goes to text interface and the phone symbol calls.
Contrast this with the standard Contacts interface. Phone, msg etc. are clearly laid out.
Signal's UX is also confusing with the id being communicated with. For example, if there are multiple numbers, hard to tell which number you are messaging.
These are all little quirks that add up to make it feel much clunkier than other interfaces.
Contrast this with the standard Contacts interface. Phone, msg etc. are clearly laid out.
Signal's UX is also confusing with the id being communicated with. For example, if there are multiple numbers, hard to tell which number you are messaging.
These are all little quirks that add up to make it feel much clunkier than other interfaces.
Video on a Mozilla page isn't playing on Firefox. Just saying...
Assuming you're talking about https://advocacy.mozilla.org/encrypt/, it works fine for me on FF 46, and they do have both MP4 and WebM sources.
It's a poor video, you're not missing much.
Painfully, it suggests "public vs private" hinges on encryption. The implication is that without encryption, your co-workers will see everything you do!
Public and private are distinct choices. Things can be private and unencrypted. Lack of encryption means lack of security in the event of a breach, it has nothing to do with choosing public vs private posts and web searches.
Works fine in my FF.
And for what it's worth, I think Apple should assist in revealing the contents of the phone if they can. I'm surprised people are defending Apple. My understanding is the request is about making the phone open to brute force attack, so it's not like encryption is under threat. It's poor password choice that's under threat. Apple does not need to compromise any other phone in doing this.
Painfully, it suggests "public vs private" hinges on encryption. The implication is that without encryption, your co-workers will see everything you do!
Public and private are distinct choices. Things can be private and unencrypted. Lack of encryption means lack of security in the event of a breach, it has nothing to do with choosing public vs private posts and web searches.
Works fine in my FF.
And for what it's worth, I think Apple should assist in revealing the contents of the phone if they can. I'm surprised people are defending Apple. My understanding is the request is about making the phone open to brute force attack, so it's not like encryption is under threat. It's poor password choice that's under threat. Apple does not need to compromise any other phone in doing this.
Without encryption, anyone on the same network - including your coworkers - can certainly see everything you do. Tools like Firesheep make it dead-simple to do.
What you're talking about is encryption of data at rest, which is a specific subset of encryption. And even then, what makes you think the breached data won't be available to your coworkers? The stuff on Ashley Madison certainly did.
What you're talking about is encryption of data at rest, which is a specific subset of encryption. And even then, what makes you think the breached data won't be available to your coworkers? The stuff on Ashley Madison certainly did.
There still needs to be a breach, and intent. The video simplifies everything down to the equivalent of shouting your private message across a room when encryption is absent, which it certainly isn't.
If you want to sell encryption, please keep it real. A hand written letter to your mother in the post is private unless intentionally and illegally intercepted. By the logic of the video, the letter is passed along and read by your neighbors before reaching its true destination.
If you want to sell encryption, please keep it real. A hand written letter to your mother in the post is private unless intentionally and illegally intercepted. By the logic of the video, the letter is passed along and read by your neighbors before reaching its true destination.
> The video simplifies everything down to the equivalent of shouting your private message across a room when encryption is absent, which it certainly isn't.
Uh, if you're on wifi or a mobile connection, depending on the configuration, it pretty much is exactly like shouting a private message across a room
Uh, if you're on wifi or a mobile connection, depending on the configuration, it pretty much is exactly like shouting a private message across a room
Except it isn't.
I could press a glass against the wall and listen to people having a private conversation. Does that make their conversation public "like shouting it across the room"? No. Of course it doesn't.
Get your analogies straight.
I could use my zoom lens to spy over your shoulder as you type your message into your super-encrypted phone. I will now publish the video on youtube, your private message now public. Serves you right for "shouting your message across the room".
I could press a glass against the wall and listen to people having a private conversation. Does that make their conversation public "like shouting it across the room"? No. Of course it doesn't.
Get your analogies straight.
I could use my zoom lens to spy over your shoulder as you type your message into your super-encrypted phone. I will now publish the video on youtube, your private message now public. Serves you right for "shouting your message across the room".
That's not how WiFi works, it's not like a wall or anything. Your device literally "shouts" (transmits in RF) your private message across the room (and into adjoining rooms). Anybody that can connect to the WiFi network (or has a decent machine and half an hour to kill) can read your message (the encryption in WiFi is fucked).
You've missed my point, again.
We live in a world where eavesdropping on a private conversation is possible because people aren't talking in a cone of silence every time they want privacy. The unlawful intent to listen in needs to be there, and then some sort of action is required to hear the conversation, such as holding a glass to a wall.
Exactly the same with digital messages. Sure, they can be listened to, but not by just anyone accidentally, as the video seems to suggest. Unlawful intent is required, and specific actions with specific software to listen in.
I'm all for encryption, but let's get something straight: unencrypted messages are not dripping down the walls for anyone to read who passes by.
We live in a world where eavesdropping on a private conversation is possible because people aren't talking in a cone of silence every time they want privacy. The unlawful intent to listen in needs to be there, and then some sort of action is required to hear the conversation, such as holding a glass to a wall.
Exactly the same with digital messages. Sure, they can be listened to, but not by just anyone accidentally, as the video seems to suggest. Unlawful intent is required, and specific actions with specific software to listen in.
I'm all for encryption, but let's get something straight: unencrypted messages are not dripping down the walls for anyone to read who passes by.
Same here. Pretty disappointing. It does work with `mpv --ytdl`, though.
Companies should be encouraged to aggressively strengthen the security of their products, rather than undermine that security.
On the other hand, I think they should most certainly not be encouraged to secure products against their users:
http://www.gnu.org/philosophy/right-to-read.en.html
What worries me the most about this seemingly frantic push for more encryption is that it will accelerate the proliferation and acceptance of locked-down, user-hostile devices. Security is important but so is freedom, and I feel like we've already sacrificed too much of the latter for the former...
On the other hand, I think they should most certainly not be encouraged to secure products against their users:
http://www.gnu.org/philosophy/right-to-read.en.html
What worries me the most about this seemingly frantic push for more encryption is that it will accelerate the proliferation and acceptance of locked-down, user-hostile devices. Security is important but so is freedom, and I feel like we've already sacrificed too much of the latter for the former...
Security requires freedom, and cannot be achieved without it. If you don't have the freedom to determine the behavior of your personal computing device, select the ways it is and isn't locked down, control updates to it, and inspect encrypted communications to/from it, that device and your usage of it are insecure.
We should not reinforce the idea that one must sacrifice freedom for security, sacrifice privacy for security, etc. Those are false choices based on fundamentally flawed definitions of "secure" and "security".
We should not reinforce the idea that one must sacrifice freedom for security, sacrifice privacy for security, etc. Those are false choices based on fundamentally flawed definitions of "secure" and "security".
Until someone develops an actually secure system that has these properties, the 'false choices' are the real choices.
Transparency is necessary for security. Full transparency requires free/libre software---we need both transparency for the implementation, and transparency for integration into the system as a whole (and, as it follows, the whole system).
Even if the system purports to be secure, that doesn't necessarily mean that it hasn't been tampered with, or that a backdoor hasn't been installed---we've had a number of examples of this lately. A fully free, reproducible system is needed here.
There's an often-used argument to dismiss this concept: that free software can still have security bugs. And then they cite recent issues like "Shellshock" and "Heartbleed". Freedom doesn't guarantee security, but it has stronger assurances than proprietary systems, where you don't even have the chance to look at and study it (to any reasonable degree); and you (collectively) definitely aren't able to modify it to suit your specific needs, study its integration with the larger system, or build it reproducibly.
Any other arguments that can be applied against free software can be applied more strongly to non-free software.
Corollary: Confidence in the security of a proprietary, secret system is always less than a free/libre, transparent one, even if the free system is provably less secure overall.
In a fully free system, it is not possible to lock down users, as the OP was concerned, because someone will just modify the software to remove that anti-feature.
Even if the system purports to be secure, that doesn't necessarily mean that it hasn't been tampered with, or that a backdoor hasn't been installed---we've had a number of examples of this lately. A fully free, reproducible system is needed here.
There's an often-used argument to dismiss this concept: that free software can still have security bugs. And then they cite recent issues like "Shellshock" and "Heartbleed". Freedom doesn't guarantee security, but it has stronger assurances than proprietary systems, where you don't even have the chance to look at and study it (to any reasonable degree); and you (collectively) definitely aren't able to modify it to suit your specific needs, study its integration with the larger system, or build it reproducibly.
Any other arguments that can be applied against free software can be applied more strongly to non-free software.
Corollary: Confidence in the security of a proprietary, secret system is always less than a free/libre, transparent one, even if the free system is provably less secure overall.
In a fully free system, it is not possible to lock down users, as the OP was concerned, because someone will just modify the software to remove that anti-feature.
I understand the general argument about transparency - without it you have to trust the person who holds hidden component.
The false premise here is that any argument that can be applied against free software can be applied more strongly to non-free software. Here are two contradictions to that:
1. The resources dedicated to securing non-free software may be far greater than those dedicated to free software because of the business interests in maintaining security. Google has done a lot to improve the security of a variety of open source projects, but only because they form part of a non-free core that would otherwise be compromised. The same holds true for Apple albeit to a lesser extent.
2. A free system can much more easily be compromised by the injection of cloaked vulnerabilities by actors such as the NSA.
You actually haven't shown anything. You have simply stated that transparency trumps everything else. This is false. Transparency simply diffuses the trust model.
More importantly, as I keep saying, nobody has ever produced a transparent system that can be substituted for Apple's system. Until they do, these arguments that a theoretical alternative would be better are imaginary. If it was as simple as you suggest, why hasn't it been done, or at least demonstrated?
The false premise here is that any argument that can be applied against free software can be applied more strongly to non-free software. Here are two contradictions to that:
1. The resources dedicated to securing non-free software may be far greater than those dedicated to free software because of the business interests in maintaining security. Google has done a lot to improve the security of a variety of open source projects, but only because they form part of a non-free core that would otherwise be compromised. The same holds true for Apple albeit to a lesser extent.
2. A free system can much more easily be compromised by the injection of cloaked vulnerabilities by actors such as the NSA.
You actually haven't shown anything. You have simply stated that transparency trumps everything else. This is false. Transparency simply diffuses the trust model.
More importantly, as I keep saying, nobody has ever produced a transparent system that can be substituted for Apple's system. Until they do, these arguments that a theoretical alternative would be better are imaginary. If it was as simple as you suggest, why hasn't it been done, or at least demonstrated?
>2. A free system can much more easily be compromised by the injection of cloaked vulnerabilities by actors such as the NSA.
I can't see how that is possibly the case. With a non free system the NSA just has to show up with a national security letter and a gag order and the system is compromised.
With the free system the NSA has to push, or get a submitter to push an update that gets missed by anybody that looks at the code.
I can't see how that is possibly the case. With a non free system the NSA just has to show up with a national security letter and a gag order and the system is compromised.
With the free system the NSA has to push, or get a submitter to push an update that gets missed by anybody that looks at the code.
> The resources dedicated to securing non-free software may be far greater than those dedicated to free software because of the business interests in maintaining security.
My argument is about confidence---you cannot trust a system that you do not have confidence in.
Yes, a proprietary system may have had much more development and research. But that doesn't make it "better". With a free system---even if it's more poorly designed---you gain confidence in being able to observe _exactly_ what it does, faults and all. You know what to expect, and what not to; that's far more important than not knowing either of those.
Further, the general recommendation among cryptographers and security experts is to use public algorithms that have been torn apart by cryptanalysts for years---all security should be in the key, for example, _not_ secrets in the implementation.
> Google has done a lot to improve the security of a variety of open source projects, but only because they form part of a non-free core that would otherwise be compromised. The same holds true for Apple albeit to a lesser extent.
This is security through obscurity, and is antithetical to actual security.
> A free system can much more easily be compromised by the injection of cloaked vulnerabilities by actors such as the NSA.
I don't follow. This is one of those situations where you _always_ have more transparency in a free system than a proprietary one---you are able to see _every_ patch that makes it into the system. That doesn't mean that you'll catch everything, but you have the opportunity to do so. And not just you---everyone.
> You actually haven't shown anything. You have simply stated that transparency trumps everything else. This is false. Transparency simply diffuses the trust model.
You cannot have confidence in an opaque system.
> More importantly, as I keep saying, nobody has ever produced a transparent system that can be substituted for Apple's system. Until they do, these arguments that a theoretical alternative would be better are imaginary. If it was as simple as you suggest, why hasn't it been done, or at least demonstrated?
Which system, in particular?
Apple's system should not be used and cannot be trusted---it is proprietary and designed to control the user in countless ways. Apple may take measures to protect their users' privacy and data, but ultimately, users are at Apple's mercy, and Apple has the final say in everything. Apple is historically one of the most opaque, secretive tech companies in existence.
So any free system is an improvement over Apple's.
My argument is about confidence---you cannot trust a system that you do not have confidence in.
Yes, a proprietary system may have had much more development and research. But that doesn't make it "better". With a free system---even if it's more poorly designed---you gain confidence in being able to observe _exactly_ what it does, faults and all. You know what to expect, and what not to; that's far more important than not knowing either of those.
Further, the general recommendation among cryptographers and security experts is to use public algorithms that have been torn apart by cryptanalysts for years---all security should be in the key, for example, _not_ secrets in the implementation.
> Google has done a lot to improve the security of a variety of open source projects, but only because they form part of a non-free core that would otherwise be compromised. The same holds true for Apple albeit to a lesser extent.
This is security through obscurity, and is antithetical to actual security.
> A free system can much more easily be compromised by the injection of cloaked vulnerabilities by actors such as the NSA.
I don't follow. This is one of those situations where you _always_ have more transparency in a free system than a proprietary one---you are able to see _every_ patch that makes it into the system. That doesn't mean that you'll catch everything, but you have the opportunity to do so. And not just you---everyone.
> You actually haven't shown anything. You have simply stated that transparency trumps everything else. This is false. Transparency simply diffuses the trust model.
You cannot have confidence in an opaque system.
> More importantly, as I keep saying, nobody has ever produced a transparent system that can be substituted for Apple's system. Until they do, these arguments that a theoretical alternative would be better are imaginary. If it was as simple as you suggest, why hasn't it been done, or at least demonstrated?
Which system, in particular?
Apple's system should not be used and cannot be trusted---it is proprietary and designed to control the user in countless ways. Apple may take measures to protect their users' privacy and data, but ultimately, users are at Apple's mercy, and Apple has the final say in everything. Apple is historically one of the most opaque, secretive tech companies in existence.
So any free system is an improvement over Apple's.
"Any free system is an improvement over Apple's"
It's hard to take that seriously.
I challenge you to name a single such system. It should be trivial since the class is so large.
It's hard to take that seriously.
I challenge you to name a single such system. It should be trivial since the class is so large.
This is simply by default, from both a free software and security perspective. I've made my security point already.
What is your argument in favor of Apple, specifically?
From a free software perspective, no non-free program is ever better than a free alternative, even if that alternative is poor, because it robs you of your freedoms.
What is your argument in favor of Apple, specifically?
From a free software perspective, no non-free program is ever better than a free alternative, even if that alternative is poor, because it robs you of your freedoms.
Right - I can see that's the belief you hold.
The part that I disagree with is the 'even if the alternative is poor'.
I understand that tolerating non-free software could be seen as moving us further away from a world where free software is the norm, but I also disagree with this.
You are arguing against Apple when the problem you are actually facing is a failure of the free software ecosystem to produce a viable alternative.
From an ideological perspective I would prefer free software too. My argument 'in favor of Apple' isn't really in support of Apple. It is against trying to tear down the current best option in favor of an alternative that doesn't exist.
There is a real fight going on right now, and favoring the government over Apple in this because you prefer free software seems like an extemely counterproductive move.
A free alternative can just as easily be outlawed as the non-free ones can. What matters is the legal and social precedents.
The part that I disagree with is the 'even if the alternative is poor'.
I understand that tolerating non-free software could be seen as moving us further away from a world where free software is the norm, but I also disagree with this.
You are arguing against Apple when the problem you are actually facing is a failure of the free software ecosystem to produce a viable alternative.
From an ideological perspective I would prefer free software too. My argument 'in favor of Apple' isn't really in support of Apple. It is against trying to tear down the current best option in favor of an alternative that doesn't exist.
There is a real fight going on right now, and favoring the government over Apple in this because you prefer free software seems like an extemely counterproductive move.
A free alternative can just as easily be outlawed as the non-free ones can. What matters is the legal and social precedents.
> favoring the government over Apple in this because you prefer free software seems like an extemely counterproductive move.
I'm not sure where you got that impression. I apologize if I was unclear.
It's essential that Apple fight this order, and essential that everyone do everything they can to ensure that this precedent is not allowed.
My comments were about the OP's comments about tradeoff between freedom and security.
As I summarized elsewhere:
https://social.mikegerwitz.com/notice/6552
We shouldn't agree with Apple's position on many things.
But it is _essential_ that this precedent---government-mandated backdoors---not be allowed. The stage on which we fight the crypto wars is shared by what would be our enemies in many other respects. So yes, we should choose our own shoes: we can stand with Apple in resisting this order while at the same time standing _against_ them for all of their other evils. This issue does not somehow legitimize all of their other evils.
I'm not sure where you got that impression. I apologize if I was unclear.
It's essential that Apple fight this order, and essential that everyone do everything they can to ensure that this precedent is not allowed.
My comments were about the OP's comments about tradeoff between freedom and security.
As I summarized elsewhere:
https://social.mikegerwitz.com/notice/6552
We shouldn't agree with Apple's position on many things.
But it is _essential_ that this precedent---government-mandated backdoors---not be allowed. The stage on which we fight the crypto wars is shared by what would be our enemies in many other respects. So yes, we should choose our own shoes: we can stand with Apple in resisting this order while at the same time standing _against_ them for all of their other evils. This issue does not somehow legitimize all of their other evils.
Thanks for the clarification - it does help.
However I still disagree with you on the point of standing against Apple for their 'evils'.
Apple is simply exercising their freedom. I agree that there may be better ways of doing things, but the failure of free software to produce these alternatives is nothing to do with Apple.
If anything, I'd say that standing 'against' Apple, works against the cause of producing a free alternative because it focuses people's attention on misplaced anger towards Apple, rather than on the constructive effort needed to build what is required.
I find it hard to see how someone reconciles a belief in freedom with an agenda that involves standing against Apple.
However I still disagree with you on the point of standing against Apple for their 'evils'.
Apple is simply exercising their freedom. I agree that there may be better ways of doing things, but the failure of free software to produce these alternatives is nothing to do with Apple.
If anything, I'd say that standing 'against' Apple, works against the cause of producing a free alternative because it focuses people's attention on misplaced anger towards Apple, rather than on the constructive effort needed to build what is required.
I find it hard to see how someone reconciles a belief in freedom with an agenda that involves standing against Apple.
> However I still disagree with you on the point of standing against Apple for their 'evils'.
We'll have to agree to disagree here---I don't want it to seem like I'm showing disrespect toward your opinions.
> I find it hard to see how someone reconciles a belief in freedom with an agenda that involves standing against Apple.
Apple is exercising a _different_ kind of freedom---a broader set of freedoms, to which they are certainly entitled. Free software represents a small subset of those freedoms---the four freedoms which are designed to protect the users, not the developers.
It's important to educate others on both the free software community's philosophy and on the problems with Apple so that they can have that comparison, and so that they can avoid Apple's products if they decide that those issues matter to them. Apple has an advantage in the number of users---one we'll never have---so we have no choice but to reach out.
We'll have to agree to disagree here---I don't want it to seem like I'm showing disrespect toward your opinions.
> I find it hard to see how someone reconciles a belief in freedom with an agenda that involves standing against Apple.
Apple is exercising a _different_ kind of freedom---a broader set of freedoms, to which they are certainly entitled. Free software represents a small subset of those freedoms---the four freedoms which are designed to protect the users, not the developers.
It's important to educate others on both the free software community's philosophy and on the problems with Apple so that they can have that comparison, and so that they can avoid Apple's products if they decide that those issues matter to them. Apple has an advantage in the number of users---one we'll never have---so we have no choice but to reach out.
You know, someone saw this problem years ahead of the rest of the cs community and started a license to help encourage user freedom. Its just a shame that I see gpl shat on so much in that community.
Personally I think RMS is a man ahead of his time, and that history will prove he has the correct view regarding user freedom.
Personally I think RMS is a man ahead of his time, and that history will prove he has the correct view regarding user freedom.
For anyone who cares about the GPL, please financially support GPL enforcement:
https://sfconservancy.org/supporter/
https://sfconservancy.org/supporter/
We are abandoning the ability to actually listen in to what our devices are doing. The great thing about the web is that hitting Ctrl+Shift+I shows you exactly what data is being sent or received whilst maintaining strong encryption. If every single thing does its own encryption we end up with a set of black boxes squirting out unreadable gibberish. Being able to verify input and output is essential.
> accelerate the proliferation and acceptance of locked-down, user-hostile devices.
We're already there. Can you read the Windows 10 telemetry?
We're already there. Can you read the Windows 10 telemetry?
On that subject, I'm kind of surprised that it's been out for months and nobody's reverse-engineered it publicly yet.
Some people said that Nexus phones that default to encrypt local storage was user hostile as there was a perceptible performance penalty. I don't think that is the case. GNU and fsf want freedom for the user. I fully support the freedoms. However, I also think that users do not have a right to force their wishes on vendors.
I think it is fair to say if you don't like the options we give you then maybe you should fork the project and build it yourself.
I think it is fair to say if you don't like the options we give you then maybe you should fork the project and build it yourself.
One of my old co-workers said it best: "Dear @SpaceX and @NASA security teams: please don't sign your firmware, in case a space gardener ever needs to bust out a hex editor."
[0] https://twitter.com/nathanmccauley/status/650450050724708356
[0] https://twitter.com/nathanmccauley/status/650450050724708356
How does that make any sense at all. What you are talking about are two orthogonal issues. How are they intertwined by necessity?
Encryption and security has always been a balance between convenience and capability. Although HTPPS and such are mostly transparent to end-user, we can see that slow adoption of public key encryption (GPG) indicates that people either need to be educated or the user experience needs to improve drastically. It's taken many years but there's a long road ahead.
> Encryption and security has always been a balance between convenience and capability.
You could say the same thing about PCs and the internet, especially during their rise to prominence.
You could say the same thing about PCs and the internet, especially during their rise to prominence.
This video is a production of the Washington DC Chapter of the Internet Society. It is meant to be a starting point for discussions about encryption, privacy, and cybersecurity.
The Internet Exposed: Encryption, Backdoors and Privacy – and the Quest to Maintain Trust
https://www.youtube.com/watch?v=F2D5dVtHXV8