Now I understand why almost no one uses encrypted email - <AUTHOR> https://cheapskatesguide.org/articles/encrypted-email.html <comment><USER2> All of this of course skates past the problem that PGP's UX practically guarantees that someone will eventually reply to an encrypted email in plaintext, often compromising the whole conversation. Practically everyone who has used encrypted email "at scale" has seen it happen. An intolerable, irrevocable disaster we accept only because most of us don't _actually_ care about the cryptographic security of our emails, most of the time.

<comment><USER3> Autocrypt is a sensible approach leveraging PGP but avoiding most of that ceremonial UX. Unfortunately the gnupg project is heading in its own direction with major clients such as Thunderbird and Protonmail following. Few clients actually implement Autocrypt.

The group that has used PGP largely seems to like the ceremony required and chooses not to understand it is an impediment for both pervasive encrypted email and usability for nontechnical users. Hell even for technical users PGP is a hassle.

I'm doing what I can to spread the word on Autocrypt, but nontech types can't or won't switch to the few clients implementing it and the PGP fanbase sees their 6 levels of trust as Zimmerman given dogma that must not be altered under pressure of earthly realities, or security insights developed after the Code was written down.

<comment><USER4> >...the PGP fanbase sees their 6 levels of trust as Zimmerman dogma that must not be altered under pressure of earthly realities, or security insights developed after the Code was written down.

I am an actual OpenPGP shill who is entirely in favour of a very conservative approach to the standard but I really don't see the problem here. Autocrypt is a separate standard. Clients can implement it completely and just switch the trust to OpenPGP if a PGP identity shows up. There is nothing wrong with a client adding some extra trust information to accommodate autocrypt.

<comment><USER3> Autocrypt requires its own separate PGP contacts database (regular PGP standard doesn't allow automatic key overwrites), and as such most MUAs prefer to limit the number of things they support to old PGP. This is a problem for adoption.

</comment></comment></comment></comment><comment><USER5> As someone who worked as a pen-tester, security is almost ALWAYS at odds with convenience.

Making better security less and less inconvenient is the name of the game. Even if 100% security would be as easy as ticking a box, though, the fact of the matter is that most people don't care and if it's not "secure by default", it simply will stay not secure.

Maybe a synonym for "turned on by default" is "absolutely zero inconvenience or attention needed"

<comment><USER6> Honestly, this makes me appreciate Signal all the more – it seems the only barrier is getting friends to adopt it, but if used by an organization could it be an alternative to E2EE email?

<comment><USER7> In my experience, the client is stupidly buggy. I've lost messages silently multiple times. This is a known issue and after losing several key messages stopped using it.

So, IMO the barrier is, "actually working"

[https://github.com/signalapp/Signal- Android/issues/5253](https://github.com/signalapp/Signal-Android/issues/5253) [https://github.com/signalapp/Signal- Android/search?q=missing...](https://github.com/signalapp/Signal- Android/search?q=missing+messages&type=Issues)

<comment> asdf-asdf-asdf it probably should be mentioned that the first github issue you linked is about signal loosing SMS-messages, not signal-messages. so for the case mentioned by the parent (" getting friends to adopt it") it is not really relevant.

<comment><USER8> One thing I've been able to tell friends is to just replace their default SMS app with Signal, since they're not particularly attached to that app anyway. Then, at least their messages to me will then be encrypted, and every additional person I get to install Signal will have an additional contact being able to use it/join a group.

<comment><USER9> This works until they either switch back to their original app or get a new phone and don't install signal on it. If you stop using Signal you need to deregister your phone number from the service, but many people don't know or care to do that.

If they don't, anyone who has ever used Signal to communicate with them will be silently unable to contact them anymore.

<comment><USER8> True. The former hasn't been a problem for me, the latter's becoming increasingly less so now that more and more people have switched, and people are starting to more consciously use it every now and then for one of the few Signal groups we have - but it certainly was a problem at first.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> It has very little to do with the UX of email encryption, IMO. People don't use encrypted email because the parties who would have to do the work in order to use it have never, and do not know anyone who has ever, suffered a problem that encrypted email would address.

Web sites use encryption because the people who would need to do the work of setting it up know that search rankings, user experience thanks to browser reporting of unencrypted connections, and consumer confidence all suffer if they don't.

And it improves their security in a couple ways too.

For encrypted email, the onus is on the recipient of email to set it up. Such a vanishingly small number of recipients have ever suffered a problem that encryption would solve, it might as well be __zero __.

We can talk about making the UX better. But unless it's effort-free and happens by default, there's no motivation.

<comment><USER11> End-to-end encryption is still a very challenging problem almost everywhere except for direct connection server-side TLS. Yet, everyone has a problem that encryption solves, which is that you actually cannot if some entity has been interfering with your email, perhaps re-writing certain paragraphs. There is plenty of evidence that actually interfering with email is in fact something that happens. Similarly, in the age before widespread use of TLS, cases of ISPs injecting content/javascript/trackers into web traffic was also widespread.

<comment><USER12> > End-to-end encryption is still a very challenging problem almost everywhere > except for direct connection server-side TLS.

Is this the case with WhatsApp and Signal? Their implementations have been working great. Why can't email work the same way?

> There is plenty of evidence that actually interfering with email is in fact > something that happens.

Please cite examples. I know Avast antivirus used to obnoxiously tamper with the emails sent by users in order to spam other people with its own advertising.

<comment><USER13> > Is this the case with WhatsApp and Signal? Their implementations have been > working great. Why can't email work the same way?

The ratchet protocol that that approach relies on requires both ends to be online at the same time. And those implementations haven't been working great. WhatsApp was definitely compromisable by an attacker who had access to the server. I have yet to be convinced that Signal couldn't be; all the descriptions of its protocol are suspiciously ambiguous about whether the attacker is assumed to control the server or the server is trusted (since the server has to be involved in allowing offline messages to work). Furthermore we've seen nothing to suggest that the NSA isn't reading WhatsApp/Signal messages; given that those systems are tightly coupled to closed-source ecosystems (and in particular closed-source "random" sources for key generation) I suspect that serious adversaries aren't even trying to attack their cryptography directly. Contrast with PGP where we know (from Snowden's leaks) that the NSA was frustrated by their inability to break it when used properly.

<comment><USER14> FUD. There are several critical flaws in your analysis (disclaimer: I'm an enthusiast, not a cryptographer).

> The ratchet protocol that that approach relies on requires both ends to be > online at the same time.

This is simply untrue, and in fact the very point of the ratchet is to support asynchronous messaging. The next ratchet's key material is sent alongside a message encrypted with the previous ratchet-derived shared key.

> since the server has to be involved in allowing offline messages to work

Sure, for some definition of "involved". But the relay server in the Signal protocol absolutely does not need to be trusted for offline messages to work, they are end-to-end encrypted.

If you don't bother to verify the security number, then you need to trust the identity server, but that's out of scope for the protocol. Verify your security numbers!

[0]: [https://signal.org/docs/specifications/doubleratchet](https://signal.org/docs/specifications/doubleratchet)

<comment><USER13> > This is simply untrue, and in fact the very point of the ratchet is to > support asynchronous messaging. The next ratchet's key material is sent > alongside a message encrypted with the previous ratchet-derived shared key.

Not true; the point of the ratchet was to allow "off the record" conversations where you would have forward secrecy, and also where the receiver would not have cryptographic proof of what you said after the conversation was ended. All of the nice security properties rely on you continuing to exchange messages regularly; it breaks down if one side sends too many messages without receiving a response from the other side, and as long as that time window is open there's a risk. In practice there's a complicated risk tradeoff around exactly how much async-ness is acceptable (both in terms of time and in terms of number of messages without a response), but any implementation will have a point at which it reverts to following protocol for sending the first message to a currently-offline user.

> But the relay server in the Signal protocol absolutely does not need to be > trusted for offline messages to work, they are end-to-end encrypted.

Maybe. It's not clear under what circumstances the server could trick the clients into treating it as a first interaction with this user, at which point the server is involved in the key exchange process - something that signal security analyses tend to brush under the carpet.

> If you don't bother to verify the security number, then you need to trust > the identity server, but that's out of scope for the protocol. Verify your > security numbers!

This is kind of a double standard though. Good practice for using PGP is to use regularly-rotated subkeys and destroy them once they're out of use, at which point you don't have a forward secrecy problem. Real-world PGP users mostly don't do this, but real-world Signal users mostly don't check security numbers either. (In contrast, real-world PGP users do check key fingerprints, in my experience, because the software defaults and the web of trust system nudge them in the right direction).

</comment></comment></comment></comment></comment></comment><comment><USER15> An emerging HN trope is that "almost no one uses PGP."

PGP remains wildly popular on Tor cryptomarkets, an area where users assume server compromise will happen yet still decide to transact using encrypted messages.

Don't underestimate a technology gaining popularity in fringe communities with young user bases, often from non-technical backgrounds. Kudos to companies like Keybase and Protonmail for investing in PGP's future.

<comment><USER16> So you mean to say is that PGP is wildly or only popular with criminals?

<comment><USER17> If criminals don't use your privacy tech, it probably doesn't work.

</comment></comment></comment><comment><USER18> Yeah, it's tedious if you do it the long way around because you, for some reason, have arbitrarily restricted yourself to only doing it via command line...

Just get an email client that has PGP capability built in.

<comment><USER19> > Just get an email client that has PGP capability built in.

That step isn't as straightforward as you might think.

Put yourself in the shoes of a complete novice. As of this writing, a Google search for {pgp email windows} returns gpg4win as the top search result, which is the tool the author used.

Otherwise, the software listed on the openpgp website ([https://www.openpgp.org/software/](https://www.openpgp.org/software/)) mostly _doesn 't_ have PGP capability "built in." In particular, both Evolution and Outlook require addons for PGP support.

Despite suffering from bad UX, the instructions the author followed are largely those present in a top-Google-searched guide ([https://yanhan.github.io/posts/2017-09-27-how-to-use-gpg- to-...](https://yanhan.github.io/posts/2017-09-27-how-to-use-gpg-to-encrypt- stuff.html) \-- infobox result for {gpg encrypted email}). Easier methods that are harder to find or less obvious may as well not exist for a novice such as the author of this article.

<comment><USER18> Sure, but the other weird thing is the author uses Protonmail... which can support PGP natively, so why the fart-arsing around ?

[https://protonmail.com/support/knowledge-base/how-to-use- pgp...](https://protonmail.com/support/knowledge-base/how-to-use-pgp/)

The whole article is basically "lol look at this thing that is actually relatively well supported with a small amount of work, but I couldn't be bothered to spend time doing some research about my use case and instead just read the first google result I found, so I'm going to crap all over it and make it look worse than it actually is for Internet Karma."

And the comment about being a novice, looking at the rest of the blog site implies the user has some level of competence when it comes to computing technologies as they are messing around with webserver configs etc.

</comment></comment></comment><comment><USER20> And the sad thing is that even if you do succeed in using encrypted email with PGP, as [https://latacora.micro.blog/2019/07/16/the-pgp- problem.html](https://latacora.micro.blog/2019/07/16/the-pgp-problem.html) says, you're taking an approach that cryptographers recommend against.

<comment><USER21> Some cryptographers? It seems to me that this article gives all the latest and greatest a free pass and nitpicks on PGP.

If PGP is criticized because a user could cc someone, how about taking a screenshot from your messenger conversation?

People do this reflexively and upload almost anything.

Why would I trust a phone (tracking device) in the first place?

<comment><USER20> I have yet to run across a cryptographer that I trust whose opinion differs significantly.

But I have no trouble finding ones that I trust who agree with the key parts of that rant. For example [https://www.schneier.com/blog/archives/2016/12/giving_up_on_...](https://www.schneier.com/blog/archives/2016/12/giving_up_on_pg.html), [https://blog.cryptographyengineering.com/2014/08/13/whats- ma...](https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with- pgp/), [https://dev.to/artis3n/encrypting-files-in-a-post-pgp- age-59...](https://dev.to/artis3n/encrypting-files-in-a-post-pgp-age-59bf) and many, many more.

Whether or not you can trust your phone doesn't change that PGP is missing nearly 30 years of what we've learned about best practices for encryption.

</comment></comment></comment><comment><USER22> I really enjoy articles like these because it offers a perspective that is difficult for developers of software to see themselves. Say you're starting a company that provides a technical service and you claim on your homepage "3-click install!" Rarely it's ever just 3 clicks. It's a good idea to watch videos or read written stories of every step a user takes in order to use your service, including learning how to use it and their mistakes.

</comment><comment> 08-15 > Each public key must be signed before messages from the owner of that public > key can be decrypted.

Nope.

> Your public key must be sent to anyone to whom you send an encrypted email.

Nope, you need theirs.

I get it, in the current year, it's cool to bash gpg because it's sooooo complicated. There may even be some merit to that argument, but it's pretty lame if the argument is based on not understanding the very basics of public key cryptography.

<comment><USER23> Seems like you are one of the only ( few ) people who caught this.

</comment></comment><comment><USER24> The UIs are terrible.

Indexing encrypted email -> difficult. Do it on the server-side and you're essentially storing the email in plaintext on a server -- you might as well have settled for hop-by-hop encryption, which is what MTAs basically try to do anyways.

Multiple devices -> yeah, that's tough too. They need the private keys. They need to keep their own indices.

End-to-end encrypted email is likely not workable. I'd settle for having hop- by-hop secure email, with a "make it secure" button on send so I can have MTAs bounce when they can't forward securely, and a "secure"/"insecure" label on inbound email that captures whether the whole path inbound was secure or not.

Another thing is that end-to-end security in general depends on introducers. CAs, etc. Meaning that the security that users who don't understand these things (99% of users) have in mind is just not what they're ever gonna get in most or all cases.

</comment><comment><USER25> I realize that this is a bit of a jerk take, but it seems that the author's problem is less with GnuPG and more with his reluctance to be careful and read a little documentation. I still have the first key I made in 2001, when a friend and I decided to try the system out. It worked the first time for both of us, and we happily exchanged a few encrypted emails. And that was the last time I actually used it - not because it's hard to use, but because nobody uses it, and I don't need to send encrypted email to myself. For about 15 years I've had an X-PGP-Key: header on my outgoing mail, pointing to a file on the web containing my public key. Not a single person has ever used it.

 _EDIT_ : No, I remember once, a few years ago, somebody did send me an encrypted message using my public key, for no particular reason. It was an amusing surprise.

<comment><USER26> For me this fits the narrative. Encryption needs to be transparent to the user in order to become ubiquitous. I assume most people are actually reluctant to read the documentation. If the tool is not self explanatory or fully embedded in the tools people use they will not see any broader adoption.

It too managed to use the tooling. But I knew what public-key cryptography is and was aware of its general concept. I do not expect anyone in my family to be able to set this up. Not without putting some time into it. And putting time into it they will only do if I pressure them to do so.

So I would say: Yes you are correct that he could have read the documentation. But from a UX perspective I do not see the failure on the part of the user.

<comment><USER25> Fair enough.

</comment></comment></comment><comment><USER27> While there is a point to be made about PGP not being user-friendly, what's wrong with having a free ProtonMail account (or creating a burner account if you're paranoid), uploading the other person's public key, and having an encrypted email exchange that way? Yes... you're having to trust that ProtonMail is actually secure but I haven't seen anyone seriously suggest that it's compromised.

That said, how hard would it be to create a fork of Thunderbird that has all of the PGP stuff build in and all you need to do is upload your private key and add a contact's public key in their address book and have an option for "always use encrypted email" (or does Thunderbird already do exactly that and I don't know because I don't use it)?

<comment><USER28> There's an addon called Enigmail that does exactly this.

</comment></comment><comment><USER29> With GPG, sure.

I have GPG keys (for other reasons) which I never use for email.

On the other hand, using S/MIME for email signing and encryption is a pleasure. At $JOB everyone get's an email cert via self-enrollment, user public certs go in AD, I can easily send encrypted email to anyone in our org.

</comment><comment><USER30> isn't the bigger issue that encrypted email is only encrypted in transit and not in place? After you send an encrypted email and it is decrypted on the other side, odds are very high that it is sitting unencrypted on the mail server or local mail client. Most email breaches are not intercepting emails in transit but rather getting credential access to email servers.

<comment><USER31> Not in this case. PGP mail or S/MIME are encrypted end to end. That said you may have a mail client which stores an unencrypted search index locally.

</comment></comment><comment><USER32> So is Autocrypt doomed to languish in lack of adoption? While it may not be perfect, it seems better than the current state of affairs.

<comment><USER33> We tried something like that at a place I worked in the late '90s and early '00s. It was for Windows users.

It inserted itself between your email client and your SMTP and POP/IMAP servers.

When you installed it, it generated a public and private key pair for you, storing them both in your local key ring.

It would place your public key in the header of your outgoing mail, and add a header that identified itself.

If you had enabled signing, it would transform you outgoing mail into a signed outgoing mail.

If the mail was going to someone who was known to use this software and whose public key was in your key ring, it would then transform your outgoing mail into an encrypted outgoing mail.

(For mail to people who were not known to have it, it put a little blurb at the bottom of the message suggesting they get it).

For incoming mail it would check the header to see if the mail was from someone using this software. If it was, it would look for their public key in the headers and add it to your key ring.

If the mail was encrypted, it would transform it to plaintext. If it was signed, it would check the signature and put something in the message to tell you if the signature check had passed or not.

The marketing people had more sway than the engineering people, so if something came down to ease of use vs. security ease of use had a good chance of winning. The marketing people were really pushing the notion that it was "transparent", and so wanted minimal configuration and minimal interaction with the user. They wanted you to just install it, get your friends to install it, and have it then transparently encrypt the mail between you and your friends.

I don't know if such a system can be made reasonably secure, but I'm pretty sure that _if_ it can be, it's going to have to be at least somewhat intrusive now and then. It needs to warn you if someone's key has changed, and provide some way for you to do an out of channel verification that the change is legitimate. There also should be some way when composing a message to indicate that it should not be sent unencrypted, and if you attempt to send it to someone whose key is not known it should be rejected.

(I'd even argue for an for flipping that last--a way to indicate that a message does not need to be encrypted, with it generating an error to try to send a message not so marked to someone whose key is not known. It should require a deliberate choice to send an insecure message rather than the other way around).

The way we inserted between the mail client and the SMTP/POP/IMAP server at first was to have our software run SMTP/POP/IMAP proxies on 127.0.0.1, and require the user to manually change their client configuration to use our proxy.

Not long after that was changed to automatically do that for various popular email clients. This was on Windows so for most of them that just meant some registry editing. I think there may have been one or two where it involved editing an actual configuration file.

I think we eventually replaced that with an LSP [1], which required no changes to email client configuration. (I may be misremembering that part, mixing it up with the LSP that I am sure we used for another product we had in the same general time frame, a pre-fetching caching web proxy).

Anyway, while technically interesting I'm not sure there is really much use for this kind of thing. You need users that need security but don't need it too badly, and are only worried about messages in transit. But it generally takes a pretty serious adversary to get your messages in transit--if you are facing that you probably need some more certain security, not something that is opportunistic.

For most people it is security at the ends that matters. It's your siblings/parents/spouses/roommates that you have to worry about, and this system doesn't really help against them.

[1] [https://en.wikipedia.org/wiki/Layered_Service_Provider](https://en.wikipedia.org/wiki/Layered_Service_Provider)

</comment></comment><comment><USER34> Another issue with encryption is the other aspect of security; malware detection. Since E2E encryption happens at the MUA level, and most spam/phishing/malware scanning is done either at the MTA level or by a gateway, detection becomes almost impossible. MUA would need to do all the extra heavily lifting. Email was designed as a plain-text messaging system. PGP, MIME and S/MIME are extensions to this, but fundamentally, email is still plain text. The key to secure email is not to use email for secure things.

</comment><comment><USER35> Encryption on the web is easy, because its automated by TLS. A far more concise answer is that email does not have an equivalent to TLS because it's architecture is not the simple client-server model like the web.

TLS is two layers of encryption. An outer layer using some form of PKI to form an encrypted pipe for the transfer of a symmetric key transfer then a more secure inner pipe based upon the symmetric key.

[https://en.wikipedia.org/wiki/Transport_Layer_Security](https://en.wikipedia.org/wiki/Transport_Layer_Security)

That is vaguely straight forward to automate provided lots of agreement around various supported standards, because the client only has to communicate with a server that will automatically respond.

Email architecture is more like client-server-server-client (and that understates many edge cases), or rather peer-to-peer with a variety of decentralized servers in the middle and the clients aren't stateful applications like how web browsers are dedicated to browsing the web. An email client on one end has no idea what the various servers and remote clients will support and when they will ever respond for a variety of technical reasons.

Since email does not have TLS key exchange is manual unless both clients are on the same server and the server owns the process for establishing key exchange, session encryption to each party, and routing between each encrypted session.

<comment><USER36> I am a layperson, so the answer is probably painfully obvious, but why can't e-mail have TLS-style key exchange, where the sender's server gets the public key from the recipient's server and encrypts the message with it before sending it over?

The recipient could keep their private key secure so that only their client could decrypt the messages, and take the risk of losing access to those messages if they lose their private key.

Or they could let their provider hold onto a copy of the private key so they don't ever have to worry about losing it, with the trade-off that the provider could decrypt their e-mails.

But either option requires zero user interaction on the sender's or recipient's part past "login and send" or "login and receive", while limiting decryption to the recipient and maybe their provider.

<comment><USER37> You could, but you're dropping the qualification of end-to-end encryption.

Brainstorms of a (mere) hobbyist:

Some might reason that that yields additional hardening to traditional TLS- enabled webmail applications.

On the other hand, that is more architectural design and work shifted away from the endpoints (and wasted, complex efforts with no added benefit if improperly implemented by the provider).

<comment><USER37> One more brainstorm,

The provider can serve key escrow and still have the end-user application perform the encryption, which may or may not technically qualify. It certainly wouldn't fly without skepticism in a popular service/standard.

I haven't looked into it deeply enough to present a confident statement either way.

</comment></comment></comment></comment><comment><USER38> Well, there actually are decent graphical interfaces for GnuPG and plugins for email clients. Doing all of this manually in the shell is not a requirement to use encryption.

</comment><comment><USER39> Maybe just use protonmail? I'm no security expert but they do claim to encrypt all emails between users on their platform. It's alot easier than this.

<comment><USER40> True. It's as easy as sending any other email there. I love when that little icon on ProtonMail lights up for end-to-encrypted but it only does that when I send mails to other PM users which are very few in total.

</comment></comment><comment><USER41> Quote: "Next, I tried exporting my public key to a file. Your public key must be sent to anyone to whom you send an encrypted email. The receiver of your message needs it to decrypt your message."

Wrong. You do need to send your or publish your public key in order for others to send you encrypted email. Messages are encrypted with public key and decrypted by you with your private key.

This is the very base that async crypto is based on.

<comment><USER42> That really only reinforces the headline though.

<comment><USER43> Hardly. It makes the headline something we can ignore. Much as if the author complained about driving their car into a tree because the steering wheel wasn't giving them feedback.

<comment><USER42> I don't imagine, if I picked 100 random people off the street, that they would get it either.

<comment><USER41> And since we live in a modern world with integration of social services only going up I strongly believe this should be taught in school, same way base computer usability is being taught in middle school. In there a simple chapter should exists to deal with this and make kids aware that cybersecurity is a must nowadays.

Then, and only then, your phrase will be false.

</comment></comment></comment></comment></comment><comment><USER44> Encrypted mail will not be "solved" until Google, Yahoo, & Microsoft decide you do something about it. Until then it's just a pipe dream.

Yes that's harsh. Yes that's what I truly believe.

And yes, unfortunately I've been right about this since 2005 when arguing about it with a colleague (Although I may not have mentioned Gmail in the list back then).

</comment><comment><USER45> These two ars technica articles are a really good breakdown on both sides of the issue, but I agree with the first.

Use keybase. It's easier!

[1] [https://arstechnica.com/information-technology/2016/12/op- ed...](https://arstechnica.com/information-technology/2016/12/op-ed-im-giving- up-on-pgp/) [2] [https://arstechnica.com/information- technology/2016/12/signa...](https://arstechnica.com/information- technology/2016/12/signal-does-not-replace-pgp/)

</comment><comment><USER46> I wonder if said acquaintance had started with something like Tutanota or DeltaChat, if the user would have had a less frustrating experience.

This sets aside that OP wrote that they didn't want to swap email providers, which I agree with. DeltaChat lets you use whatever provider you want, but it is in a mobile app format and can only use one account at a time.

If they could make DeltaChat support multiple accounts and while we're pipe- dreaming, a desktop version, I would use it for almost all non-Signal conversations, real emails or otherwise.

</comment><comment><USER47> Sorry but this is not about encrypted email but the sheer suckiness of GPG.

PGP enccrption works flawlessly with protonmail. I've created a word document constituting about 5-10 screenshots of how to setup s/mime on outlook/windows for people who know little of it and it worked with minimal issues.

However GPG is the one tool that I find has just about the worst UI.

That said, I think we should tell people to switch to E2E messaging where possible and email needs a replacement, not another layer of complexity.

</comment><comment><USER4> Whatever guide they were using must of been terrible. Unfortunately they failed to specify which one it was so it is hard to know what went wrong here. Still, as learning experiences go this could of been much worse.

I suspect that most people would just of used some sort of email client with this stuff built in rather than doing it completely manually...

<comment><USER48> So what guide would you recommend?

<comment><USER4> Riseup.net has a fairly extensive discussion:

[https://riseup.net/en/security/message- security](https://riseup.net/en/security/message-security)

FSF is a bit more to the point for the casual user:

* [https://emailselfdefense.fsf.org/en/](https://emailselfdefense.fsf.org/en/)

It is not always clear to the casual user if they are using gpg1 or gpg2. You pretty much always want to use gpg2. This is a genuine issue with the gpg ecosystem.

</comment></comment></comment><comment><USER49> Why can't secure email be based on simple https-server?

I assume the server would need to store the messages in plain text, or maybe not, but the communications to and from the server should be safe with https, no?

You would not need to trust such a web-server any more than you currently trust you email provider. But it would be much safer. Why not?

</comment><comment><USER50> "Here's my burner number, hit me up on Signal."

job done, assuming you want to transmit files under 100 MB/message.

<comment><USER15> Safe communication in 2020 does not require buying a tracking device and sharing its ID number.

</comment></comment><comment><USER51> >And, unless you are someone like Edward Snowden with huge secrets to reveal, probably no one will be willing to expend the effort to hold an encrypted email conversation with you.

Not to mention even Glenn Greenwald did not expend the effort to learn GnuPG, even when Snowden sent him a 10 minute tutorial.

</comment><comment><USER52> I can feel the pain reading that post.

I'd suggest it might be easier and "good enough" to just use symmetric encryption. Tell your friend the password you both will use and just use "gpg -c plaintext.txt".

<comment><USER53> Or even "zip -e", for people who don't have gpg installed. I use this all the time. It takes care of 90% of my needs, and even non-technical people understand how to deal with it.

</comment></comment><comment><USER54> I consulted for a company named FlowCrypt last year. Best email encryption UX of any I've seen. Open source and free-for-most business model.

Highly recommend for personal use.

</comment><comment><USER55> It seems like a very bad design that email messages from criminals and scammers are virtually indistinguishable from email messages from your bank.

<comment><USER24> Criminals and scammers sure like that though.

</comment></comment><comment><USER56> GPG4Win has a GUI for keys and an Outlook plugin .. went smoothly for me. I have had enough of command line interface in my Micro VAX days)

</comment><comment><USER57> Is it already time for the weekly "GPG has a bad interface" blog post?

</comment><comment><USER58> This article ignores certified email built into almost every email client.

I recently experimented with Thunderbird and Mac Mail because I wanted to set up encrypted email, and I wanted to move from GMail to one of my domains through RunBox.

Both clients are set up for encrypted email through certificates. The UI is pretty slick in both cases, the docs looked pretty clear!

What I found as I tried to send an email saddened me: obtaining a signed personal certificate with a CA is nigh impossible (self-signed is easy, but useless). I have some friends in the military who's certs are on my keychain because they are signed by .mil, but for us schlubs? There's really no alternative that I could find that is trusted.

Seems like if personal certs could be offered by a reliable CA, it would be pretty damn easy to use encrypted email.

<comment><USER59> I'm lucky enough to still have a job in a crisis. If that weren't the case, then a pet project of mine would be a LetsEncrypt-like service for personal certificates. Certificates you could install in your browser for TLS authentication, and some templates and examples showing how to configure nginx to authorize clients using one. I imagine email would be pretty similar. I'm just not as familiar with how to configure email clients to use certificates.

<comment><USER60> There were several free SMIME certificate providers, who would issue you a personal certificate verifying that you control a given email address.

Most have shutdown their free products in the past few years, I suspect as a result of having to invest money in their decades-old web applications that no longer function correctly in modern browsers.

One remains, but this blog post warns that they practice unsafe private key practices, so I'm inclined to suggest that none do.

[https://davidroessli.com/logs/2019/09/free-smime- certificate...](https://davidroessli.com/logs/2019/09/free-smime-certificates- in-2019/)

</comment></comment></comment><comment><USER61> 15 minutes could save you 15% on your cybersecurity insurance or more: [https://github.com/DataDog/yubikey](https://github.com/DataDog/yubikey)

<comment><USER62> macos only guide? What about windows users?

</comment></comment><comment><USER60> Secret decoder rings are cool, but they're not popular and they never will be. Most people just want a glued envelope and a locked mailbox, not ciphertext. If you want to advance the cause of encrypted email for everyone, and you operate a mail server, make sure it sends and accepts encrypted SMTP connections.

Which of these 'encrypted email' use cases is the one that's desirable to people with regards to email, using postal mail as an analogy?

1) Letters to you can only be read by you, using a secret decoder ring to ensure that no one else can.

2) Letters to you will usually only be read by you, unless someone takes the letter from your mailbox and opens it.

3) Letters to you will usually only be read by you, unless the government is spying on you and X-rays the envelope in transit.

4) Letters to you could be read by anybody and that's fine with you, since they're openly written on the back of a postcard by the sender.

Loosely, these analogies translate as: GPG is #1, TLS SMTP is #2, SMTP is #3. (There's not really an analogy for #4.)

A few years ago, Gmail finally added a simple lock icon summarizing whether an email was encrypted-in-transit or not. SMIME (#1) is green/locked, TLS SMTP (#2) is gray/locked, SMTP (#3) is red/unlocked. This single icon has probably done more to advance the cause of encrypted email than the previous twenty years of PGP/GPG, and the number of red icons in my email has fallen dramatically over time.

That feature was discussed on HN at the time (4 years ago, 209 comments): [https://news.ycombinator.com/item?id=11067050](https://news.ycombinator.com/item?id=11067050)

<comment><USER63> > 2) Letters to you will usually only be read by you, unless someone takes the > letter from your mailbox and opens it.

That's not a great analogy because removing a physical letter from your mailbox and opening the envelope leaves physical evidence of tampering. It's also a felony, with a disproportionately severe punishment, if you're not the designated recipient of the letter. Reading an email at rest on a server somewhere leaves no evidence that the content was leaked and is unlikely to be punished. In the absence of physical evidence when a message is intercepted, or practical recourse when the privacy of the communication is violated, I for one would very much prefer option #1—end to end encryption. Frankly if there were a system as easy as GPG for end to end encryption of physical letters, I'd prefer that as well.

GPG does clearly have UX issues. The manually curated web-of-trust was a good idea in principle but too much work to really catch on at scale. Encryption needs to be enabled not only by default but unconditionally, with transparent key exchange and some form of automatic, distributed reputation tracking. The system that fixes these issues probably won't be built on top of SMTP or interoperate with existing email clients, if only because encrypted email cannot be made mandatory without breaking compatibility anyway, but it will serve the same function of facilitating asynchronous, long-form written communication.

<comment><USER60> It's enough of an analogy to make the point, though. Most people's needs for letters security are option #2, not option #1. If you can get the email from source SMTP server to destination mailbox encrypted over the wire, then most people don't care if someone _could possibly_ look at it in your mailbox. And, very few people mind that the "lost letters" division of the postal service opens their mail and packages to try and return it to them when something goes wrong.

While I understand that in an ideal world, #1 would be perfect — in today's real world, #2 would be better than the often-unencrypted mess we have today. I've seen a lot of personal mail servers that no one set up encrypted SMTP on, and yet their owners have GPG keys published and signed. Transport encryption and end-to-end encryption are not conflicting goals.

I refuse to accept the defeatist view that "encrypted email cannot be made mandatory without breaking compatibility anyway". I'm not interested in building an encrypted utopia that doesn't interoperate with email. Every social network and web forum for the past 20 years has tried to do this, and none of them have replaced email at all.

I'm interested in protecting people who think that email should be safe in transit — the same expectation that postal services give them about their mail today — by seeing everyone who operates an email server enable transport encryption. It's not a big ask, and it doesn't prevent GPG from succeeding.

But it might have prevented some random person who probably doesn't need ciphertext encryption from wanting to use GPG if they'd realized that option #2 was in place for them, and thus prevented this entire article's UX nightmare at all.

<comment><USER63> > Transport encryption and end-to-end encryption are not conflicting goals.

On that we agree. It's better to have both. Even if you already have end-to- end encryption for the content, transport encryption helps to avoid leaking metadata about who the message is being delivered to.

> I refuse to accept the defeatist view that "encrypted email cannot be made > mandatory without breaking compatibility anyway".

Whether you accept it or not, if you reject unencrypted messages, or insist on only sending encrypted messages, then you aren't interoperable with today's email system. That's not a defeatist view, it's just being realistic. And as we've seen with GPG, if you don't insist on encrypting everything then encryption will not be used—or worse, it will be used inconsistently, as in the case of someone sending an unencrypted reply which quotes an encrypted message.

> I'm interested in protecting people who think that email should be safe in > transit — the same expectation that postal services give them about their > mail today — by seeing everyone who operates an email server enable > transport encryption.

Plain email can be improved somewhat but it's still essentially the same as writing your message on a postcard. Transport encryption is akin to physical custody of the mail; it's useful but not sufficient. The only people who would see your postcard while it's in transit are postal workers, and yet people still use envelopes to keep their messages private _from the people handling the mail_. Transport encryption does nothing to help in that area and _does not_ fulfill the expectations that people have in regard to postal mail, which are based in large part on legal codes and physical properties which do not apply to email. To get something similar to a message in an envelope the content must be encrypted end to end, not just at the transport layer.</comment></comment></comment></comment>


Making a REST API with Play - <AUTHOR> http://developer.lightbend.com/guides/play-rest-api/index.html <comment><USER2> OK, nice. How is it any better than exposing functions with XML-RPC and any random ORM?</comment>


4G LTE protocols used by smartphones can be hacked, researchers found - <AUTHOR> https://www.cyberscoop.com/4g-lte-protocols-used-smarthphones-can-hacked-researchers-found/ <comment><USER2> This is really not much of a story, despite the exciting headline.

The claim is that IPSec core networks can be subjected to a denial of service, and that this will result in a DoS for the users. That's correct but not very interesting.

The researchers then go on to note that a DoS on 4G specifically can put users into a vulnerable position by shoving them over onto 2G networks, which _are_ very vulnerable. But at the end of the day it's still only a DoS on LTE-- what you've switched to after that is not LTE's problem.

That's not to say the LTE isn't vulnerable, of course. Breaking data plane crypto at the ENB means that limited physical penetrations convert them into very effective surveillance tools. And the data plane crypto isn't great (lacks integrity protection). I've suspected in the cold quiet of my heart that some operators run EIA0 in production. Etc.

So, yay for DoS, but I wish people would use the word "hacked" a bit more clearly, or drop it all together.

<comment><USER3> > people would use the word "hacked" a bit more clearly

It gets more clicks though nowadays. Bad password discipline ? It's a hack !

> shoving them over onto 2G networks

Wonder why Android doesn't have a setting to lock on LTE/4G as it does for 3G, maybe in the future when LTE is more widespread.

<comment><USER4> Could be that by default LTE is only a data carrier.

Until you can be reasonably sure that there is VoLTE support everywhere, restricting the phone to LTE service means you lose out on call capability. And that is likely to be a big nono for emergency reasons. After all, a phone without a SIM can still call the national emergency numbers around the world.

<comment><USER5> > After all, a phone without a SIM can still call the national emergency > numbers around the world

This is actually not true in every country

</comment></comment></comment></comment><comment><USER6> It's my perception that smart phones and their surrounding software, hardware, and protocols are _very very hackable_ outside of the basic kernel and app- level systems.

The baseband cpu is out of your control, the encryption is legendarily bad, the protocols are MITM'able, the kernel is subject to patches from your cell phone company...

<comment><USER7> Nearly all phones use a baseband from qualcomm. It has rather poor security. I'm sure if you looked hard enough you could find a remotely accessible one

</comment></comment><comment><USER8> > SS7 was in the news earlier this year after a 60 Minutes exposé led to calls > for a congressional investigation and a FCC review.

It was? Why didn't I hear about this? I don't remember this coming up on HN. That is interesting that the mainstream media would take an interest in that considering SS7 security was relatively an obscure subject until recently in the tech community.

>> In his letter to FCC Chairman Tom Wheeler, Lieu said the flawed SS7 system provides an open door for foreign hackers who want to intercept the private communications of U.S. government officials. [https://www.wirelessweek.com/news/2016/08/congressman- urges-...](https://www.wirelessweek.com/news/2016/08/congressman-urges-fcc- speed-investigation-ss7-flaws-light-dccc-rccc-hacks)

I don't think there has been enough research into the risks of these mobile networks. Not just from external attack but exploitation by domestic nation states to deploy malware onto peoples phones, mass location tracking, social network modeling, etc.

The amount power these ubiquitous towers provide any nation state with a modern security service and a penchant for secrecy is definitely underrated. Forget all of those quotes from the US founding fathers about gun ownership as a necessary affront to tyranny, controlling the communications networks makes any type of internal non-political rebellion against the state a long lost idea.

<comment><USER9> There has been plenty research into mobile networks by people who have the resources to acquire the necessary test gear and documentation, aka nation states and intelligence services.

It's just that they have decided they would rather keep us all insecure than lose the ability to deploy their little spy toolkits on journalists and such.

Cool talk from Nohl where they deploy a location tracker over the air to the SIM card:

[https://media.ccc.de/v/30C3_-_5449_-_en_- _saal_1_-_201312271...](https://media.ccc.de/v/30C3_-_5449_-_en_- _saal_1_-_201312271715_-_mobile_network_attack_evolution_-_karsten_nohl_- _luca_melette)

If I remember correctly, that wasn't even a bug, but a feature mixed with insecure configuration.

</comment></comment><comment><USER10> The actual research presentation is here (by Nokia Bell Labs researchers Silke Holtmanns, Bhanu Kotte and Siddharth Rao):

[pdf]: [https://www.blackhat.com/docs/eu-16/materials/eu-16-Holtmann...](https://www.blackhat.com/docs/eu-16/materials/eu-16-Holtmanns- Detach-Me-Not.pdf)

</comment><comment><USER11> Denial of service attacks against networks where devices need to be authorized to connect? A little bit of an overreaching headline.

<comment><USER12> They don't need to be authorized to attempt to connect, or to spam the channel with unrelated frames.

</comment></comment><comment><USER13> It is facinating how complex 4G networks are, compared to SS7 powered networks. It's like Boeing 747 compared to the ww2 war planes. Obviously, you have more vulnerabilities on the larger attack surface.

<comment><USER14> The complex is more on the IMS side. Everything else in 4G is a bit simpler. Fewer and less arcane protocols, a bit fewer nodes.

</comment></comment><comment><USER15> Of course its a proof of concept

</comment><comment><USER16> They mention a good counter measure is to install lots of Firewalls, I agree with that. Oh, BTW, Nokia happens to have them available for purchase... I don't want to seem too cynical here but... sounds a little like maybe the idea is to generate some buzz for their FW product ?</comment>


Introducing power saving mode in Opera for computers - <AUTHOR> https://www.opera.com/blogs/desktop/2016/05/introducing-power-saving-mode/ <comment><USER2> > We are the first major browser to include a dedicated power saving mode

Isn't that because the one prime power-saving browser (Safari) is simply power-saving by default? AFAIK it's the same story on Windows (with Edge).

Chrome is well known for being an all-power-consuming monster, having better power consumption than Chrome is hardly an achievement.

<comment><USER3> There's also Firefox (I don't know much about Firefox power consumption. )

<comment><USER4> On Windows at least it looks like it's considerably better than Chrome but less good than Edge / IE: [http://www.digitalcitizen.life/test-comparison- which-browser...](http://www.digitalcitizen.life/test-comparison-which- browser-will-make-your-laptop-battery-last-longer)

<comment><USER5> > All the web browsers used their default configuration, without any add-ons > or toolbars installed.

My raw, untested guess is that using Firefox with some strict adblocking/flashblocking etc. tools might reduce its power usage due to less HTTP requests, less CPU/GPU time wasted (though OTOH the add-ons may increase the CPU load to do their job, so it's non-obvious).

</comment></comment></comment></comment><comment><USER6> > first

explorer 9 disagrees.

[http://www.sevenforums.com/tutorials/159269-internet- explore...](http://www.sevenforums.com/tutorials/159269-internet-explorer- javascript-timer-frequency-power-plan-settings.html)

Safari says hi as well

[http://www.imore.com/os-x-mavericks-preview-safari-power- sav...](http://www.imore.com/os-x-mavericks-preview-safari-power-saver-cuts- flash-knees)

</comment><comment> awinter-py G chrome has a 'power multiplier' that you can turn on by clicking the red multiplication sign next to each open tab

</comment><comment><USER7> They aren't comparing apples with apples. Ad blocking is only enabled in the power saving mode. This alone would save a lot of CPU. IMO they should show a comparison with ad blocking enabled in both situations.

</comment><comment><USER8> Does anyone know how different is power management of Chrome on ChromeOS from Chrome on other OSes? Chromebooks are known for long battery life is that because of power management or is there more in this?

<comment><USER9> Minimal hardware + even more minimal software stack means that there's little _except_ Chrome that can drain power. That already helps a lot.

</comment></comment><comment><USER10> Chrome should add such a mode, too. Power consumption is a big concern for laptop users.

<comment><USER11> Why don't you just make low power consumption a permanent feature?

<comment><USER12> It's really frustrating how much the web, software, and computers in general are being gimped for everyone just to support the "mobile" segment of the market.

<comment><USER2> Nothing is being "gimped" for the benefit of laptops, and paying attention to power consumption (direct or indirect) benefits pretty much everything.

</comment></comment></comment></comment><comment><USER13> This smells fishy to me.

Why did they test in High Performance power mode? The default is Balanced.

High Performance mode doesn't allow the CPU to downclock, keeping it at the maximum frequency at all times, even with zero load. It also maintains a higher screen brightness, and stops wifi and disks from entering power-saving modes too. This is NOT a negligible difference.

The _concept_ behind optimizing for energy savings in a browser is absolutely brilliant. Why pollute it by using such blatantly fake numbers?

<comment><USER14> Using HPM eliminates confounding factors. You won't get real world numbers because some of the benefit is provided by the OS/hardware, but you'll know if your changes are actually making a difference during the times that they are active.

<comment><USER13> It's simply not an appropriate test. You don't use high performance mode when you care about battery life.

<comment><USER15> I don't get your objection here. Not only does high-performance mode eliminate OS-level confounders that would otherwise render consumption deltas highly questionable, it does so in a way that produces _worst-case_ results.

What exactly are you complaining about?

<comment><USER13> All that other stuff impacts battery life in a huge way. Those variables matter. You can't just remove them, call it a "worst case scenario", and walk away. That is not valid.

When a reputable site like Anandtech reviews a laptop, they don't force it to maximum performance mode, because nobody that cares about battery life would ever do that. It's testing a scenario that _doesn't matter_.

In fact, not only is it not the default, but maximum performance mode doesn't even _show_ by default-- you need to expand a "show additional plans" dropdown in the power control panel to see it. Opera went to the trouble to do that, and it was not by accident.

<comment><USER14> I think you're looking for a followup study that complements these results, but that study would be not as valuable as with these to inform their interpretation.

</comment></comment></comment></comment></comment></comment><comment><USER16> If you want to see a hard to justify CPU hog, take a look at the amount of CPU Chrome or Firefox use for downloading a file. Then compare it to wget.

</comment><comment><USER17> Reminds me of Intellij IDEA's power saving mode.

</comment><comment><USER18> This is my very unscientific method, but it really seems to work. On my i7-4510 with FF I was using 7500mW. With opera I am using 5500mW. That is a pretty good savings. The only issue I am having is three finger swiping to go back and forth doesn't seem to work.

</comment><comment><USER19> How does it fare compared to dillo ? That's right.

</comment><comment><USER20> Opera trying hard to survive these days. I would use it if they open their source code

<comment><USER21> Opera is staging and making some last minute "value adds" before selling to a Chinese Tech company: [http://www.bloomberg.com/news/articles/2016-02-10/opera- soft...](http://www.bloomberg.com/news/articles/2016-02-10/opera-software- gets-agreed-takeover-offer-valued-at-1-2-billion)

It has nothing to do with surviving. They just want to cash out.

</comment></comment><comment><USER22> Power consumption improves a lot with malware filters.

</comment><comment><USER23> Decided to install opera, discovered there's no way to disable speed dial and I was out of there. Why would I want a browser I can't control?

<comment><USER24> Hmm, kinda odd. Not sure if you are comparing this to Chrome, Safari or Edge but with those you have a lot less control over the start/speed-dial page. Use the gear icon in the upper right to edit nearly everything on the speed dial page including turning speed dial off.

One of the main reasons I switched to Opera was the ability to have more control over the start page.

The biggest reason to switch to Opera now is the ad blocker is much faster than ABP/Ghost/etc and web pages load significantly faster now.

<comment><USER25> With chrome you have more control over the start page, in that you can change it from the default one to a totally different one, but when comparing opera's speed dial to chrome's default start page Opera's is definitely far superior (and more customizable). The speed dial is the main reason I use opera as well (I like it much better than any speed dial addons for chrome/firefox, and even vivaldi's speed dial)

edit: apparently there are opera addons that allow you to load a custom page instead of the speed dial so that may also be a moot point anyway</comment></comment></comment>


As a new user my first post got deleted? - <AUTHOR> It looks like my first post disappeared or became invisible as soon as I posted it.
I'm not trying to be a spammer! I just asked a legit question, though maybe a boring one.
What did I do wrong, and how can I do better next time? <comment><USER2> It got hit by a spam filter. Sorry about that; those are tuned more aggressively for new accounts. We've marked your account legit so it won't happen again.</comment>


WhatsApp discloses vulnerability; Israeli spyware was installed on iPhones - <AUTHOR> https://9to5mac.com/2019/05/13/whatsapp-vulnerability-israeli-spyware/ <comment><USER2> Extensive discussion: [https://news.ycombinator.com/item?id=19904581](https://news.ycombinator.com/item?id=19904581)</comment>


Status.im puts $5M into Matrix.org to fuel FOSS decentralised comms - <AUTHOR> https://matrix.org/blog/2018/01/29/status-partners-up-with-new-vector-fueling-decentralised-comms-and-the-matrix-ecosystem/ <comment><USER2> Its crazy how the Status market cap used to be at around $2B [https://www.coingecko.com/en/price_charts/status/usd](https://www.coingecko.com/en/price_charts/status/usd)

</comment><comment><USER3> Sure, there are lots of crappy blockchain shitcoin stories coming out every day.

But then there are very interesting, motivating stories like this one!</comment>


Taking Efficiency To Its Limits: A Train That Doesn't Stop For Passengers - <AUTHOR> http://www.treehugger.com/files/2008/06/taking-efficiency-to-its-limits-with-a-never-stopping-train.php <comment><USER2> That is actually really cool. I thought it was going to be an article/metaphor about technology tightening the spiral of efficiency to the point the side effects that served its creators as the purpose are seen as dead weight.

Or a slight at ruby on rails/35 signals quest to deliver the minimum amount of functionality and charge for it. you know rails, trains, passengers/customers etc.

<comment><AUTHOR> I liked it because when I first saw the headline, I couldn't imagine how a train could do that. Watched the video and it seems so obvious now. Innovation is cool.</comment></comment>


Conversion statistics, as told by the Princess Bride - <AUTHOR> http://www.eventarc.com/posts/2010/05/18/conversion-statistics-rodents-of-unusual-size-and-the-finest-swordsman-that-ever-lived/

<comment><USER2> i suspect that most hacker minds are cool with raw data but i found that the storyline made it easier to digest. if you were to ask me about the company and #s tomorrow, i'd still remember.

but maybe that's b/c the Princess Bride is one of my favorite movies.

either way, props on the creativity.</comment>


How is the Covid-19 pandemic affecting international tech hiring? - <AUTHOR> https://relocateme.eu/blog/how-is-the-covid-19-pandemic-affecting-international-tech-hiring/ <comment><USER2> What hiring?

<comment><AUTHOR> Hiring software engineers and other IT professionals from abroad

<comment><USER2> I think you missed my point: just about every company that is not in life sciences or some critical supply chain is scaling down, laying off people or simply hanging on for dear life. International hiring, tech or otherwise, is over and done with for the foreseeable future.</comment></comment></comment>


Novel optics for ultrafast cameras create new possibilities for imaging - <AUTHOR> http://news.mit.edu/2018/novel-optics-ultrafast-cameras-create-new-possibilities-imaging-0813 <comment><AUTHOR> The YouTube video was more impressive, the main point being they can shrink a 30cm lens to 3cm, going on to say this could one day be used in phones to remove the lens bump:

[https://www.youtube.com/watch?v=XWxYiMQ5tdI](https://www.youtube.com/watch?v=XWxYiMQ5tdI)</comment>


It's "GitHub meets Shopify": Binpress sells your source code - <AUTHOR> http://thestartupfoundry.com/2011/02/04/it%E2%80%99s-%E2%80%9Cgithub%E2%80%9D-meets-%E2%80%9Cshopify%E2%80%9D-binpress-sells-your-source-code/

<comment><USER2> Do people really buy source code? I would think raw source code is of limited utility. A lot of the value is in the heads of the people who wrote it.

If you sell source code do you have to include some amount of training/consulting to hand it off?

What kind of source code are people buying? Libraries? Windows applications? Finished web apps?

<comment><USER3> Are you kidding? Raw source code has huge utility! Many companies build businesses upon open source software, and this is really no different except they're paying for the code.

Understanding the API and integrating it into the current system is all most companies need or want to do, so buying some code off the shelf is a LOT cheaper than the development effort, and in many cases actually _less_ risky, even if they don't fully grok the full source.

Of course, support can be sold separately. But that doesn't mean the code itself doesn't have value. Right now I'm using dozens of OSS modules, most of which I'd be happy to pay some money for because of the time they've saved me and my business.

<comment><USER2> I think there is a continuum, from fully supported proprietary executable to tar dump of abandoned code.

When I pick an open source library to use, the continued active development, documentation, and support community around it are my main criteria. Much the same is true of commercial software.

I have little interest in downloading some random source code off the internet. Maybe that's not what's for sale on these sites but that's what it sounds like from first glance.

If you're selling commercial components, why not set up your own website and sell it there?

</comment></comment></comment><comment><USER4> This is awesome. I sell code (non-exclusively) on Codecanyon so they take 75%. Only taking 30% is huge for me.

<comment><USER5> I think you've identified their problem, you're their target audience AND you're not 100% happy with their competitor yet you don't know about their service!

They definitely need to work on that, maybe that will solve their chicken and egg problem!

<comment><USER6> It is definitely something we are working on (I'm one of the co-founders). We've just launched and it will take some time before the words spreads around - codecanyon has been around for over a year and a half. Features like this certainly help

</comment></comment></comment><comment><USER7> Have you considered a consumer petition side as well? My immediate thought upon looking at this (late on a friday night) is "I'd like to sell something here, but I'm not sure what people want that isn't here."

<comment><USER6> That is a very good question - we actually thought about that, and are about to launch a section for wanted components - people can suggest what they need and discuss it. Developers can pick up ideas from those

Check out <http://www.binpress.com/wanted/list>

</comment></comment><comment><USER8> What I really want is an easy way to donate to any open source project or pay for development of features/bug fixes.

<comment><USER9> I think this is a great idea, a bounty system.

</comment></comment><comment><USER10> How to fund software development, without the problems of proprietaryness or antifeatures, is the perpetual quandary of our time.

A possible method might be what I'd call "code shares". Here the author of some code might receive payment for support in the traditional manner, but because the authors resources are limited they might issue a number of shares, perhaps corresponding to lengths of time. Like other kinds of shares these would have a valuation, and customers could buy or sell shares amongst themselves. Each share is basically an entitlement to a certain amount of support for the given code base. Cryptographic methods could be used ensure that shares are unique.

</comment><comment><USER11> they should sell their own source code and be meta

</comment><comment><USER10> I'm not sure that this is really going to work very well. A better approach might be a bounty system. Another approach might be a method by which you can buy support for specific code bases, but this may not scale well and suffer from the same problems as "open core".

</comment><comment><USER12> I think this is a great start, but there doesn't appear to be enough detail in some of the classes/libraries for sale. For example, there is an interesting scaffolding class but the details provided are very limited. There's no compatibility list regarding what databases it works with, or how customizable the output is via the object's functions. I understand not exposing the source code of a for sale library, but there should definitely be auto-generated API docs for each class, in this way I have a better understanding rather than just a limited demo, clearly in this case $29 isn't a big deal, but it does add an unnecessary layer of doubt.

<comment><USER6> There is actually auto-generated API doc for that component, but it should probably be featured in a more prominent place. Thanks for the feedback

</comment></comment><comment><USER13> Is this only for web development libraries? I think there will be a huge market for iPhone/Android libraries.

<comment><USER6> Currently it's only for web development - we will be adding mobile and desktop development environment in about a month or two.

</comment></comment><comment><AUTHOR> As a side note, the guys who work on Binpress are very nice people. It was really easy to pick up on even via email.

</comment><comment><USER14> If someone sells source code that they do not have the rights to (open source or someone else's code), is Binpress liable?

</comment><comment><USER15> I don't know how The "Startup" "Foundry" is going to "take on" "TechCrunch" with their "unnecessary" quoting.

:(

<http://www.unnecessaryquotes.com/>

<comment><USER15> Why the hell am I being downvoted? They used unnecessary quotes (amateur mistake) in their title, and a previous mention on the HN homepage suggested they were going for the jugular of TC.</comment></comment>


Jira: Thumbs up or Thumbs down? - <AUTHOR> What is your overall opinion about Jira?<p>Thumbs Up or Thumbs Down? <comment><USER2> Too complicated to use, especially in roles and permissions. I don't need a Ferrari,where a bicycle will do just fine.

<comment><AUTHOR> True. It is probably very powerful but is very complicated to use and get started.

Have you considered alternatives?

</comment></comment><comment><USER3> A PITA to configure.

Magnificent if configured right (hint: simplify, simplify; provide use-case- customized simplified kanban boards and issue filters to anyone who doesn't want or need the complexity).

Irreplaceable for reasonably tech-savvy project managers.

And the new UI may be more modern and mobile friendly but is harder to use on desktop than the old one.

<comment><AUTHOR> Yes. configuration takes a lot of time and it is not easy to get started. Have you considered alternatives that are worth looking at?

<comment><USER3> Everything else I've looked at falls short in one or another crucial way. The closest has been Phabricator, which felt clunky in comparison (granted, it's been a few years now since I've used it.)

<comment><AUTHOR> Codegiant and Scrumpy look like good alternatives atleast for me.

</comment></comment></comment></comment><comment><USER4> Down. Functional but over-engineered.

I don't like wondering if the page will just hang or go blank when I touch one small thing.

<comment><AUTHOR> Yes. It's become complicated due to the high number of integrations that it supports. It does make it useful, but it has been over-engineered like you said.

What alternatives have you considered? I found a couple of good ones recently Codegiant & Scrumpy, and evaluating between them currently.

<comment><USER4> The only other ones I've used for any serious amount of time were Bugzilla, Trac and ClearDDTS. I also dabble with GitHub Issues.

Bugzilla is another functional-but-not-ideal one. It just seemed bulky somehow; I don't tend to want a lot.

Trac is probably my favorite but it tends to work best if you can adopt it all at once (code, wiki, etc.). At the time I was using Subversion, which it could tie into well. I don't know if it handles "git". It has a nice wiki format. Everything cross-links easily.

DDTS is quite old but was surprisingly robust and versatile (probably not even sold anymore though). It had a very Unix-style design with many commands, text file formats with a side database, and a web wrapper over it all that has page templates, etc. It does issue tracking and as far as I know it doesn't integrate with anything else (no special knowledge of revision control...maybe ClearCASE?).

</comment></comment></comment><comment><USER5> Terrible.

<comment><AUTHOR> What are you using as a replacement to Jira?</comment></comment>


Hugo Chavez's economic miracle (2013) - <AUTHOR> http://www.salon.com/2013/03/06/hugo_chavezs_economic_miracle/ <comment><USER2> The old resource curse. Oil drives out investment in anything else, and when oil drops you are fubar

<comment><USER3> Better title would have been, Oil's Economic Miracle. A follow-up written today would then be titled, Miracle to Curse: How The Oil Crash Crashed Venezuela.

</comment></comment><comment><USER4> I really would like to hear what would these people say now.

I bet in: "When the facts change, I change my mind. Don't you, sir?"

<comment><USER5> Or they'll say what's happening in Venezuela is due to some American scheme to take down their government (like some have ridiculously claimed about Brazil).

The life of Latin American wannabe dictators is so easy. When things go wrong, just blame the imperialists.

<comment><USER6> Did you saw that weird thing, saying that CIA was responsible for Mandela's arrest? These people' creativity has no end....</comment></comment></comment>


BTFS – mount any .torrent file or magnet link as directory - <AUTHOR> https://github.com/johang/btfs <comment><USER3> This is effectively what IPFS is, but IPFS takes it to the next level by using the equivalent of torrent files for subdirectories within the mounted torrent files, so you can "traverse" entire networks of the pretty-much-a-torrent files without first having to download and mount them. And like, you could implement similar functionality here by having torrent files that contain files named .torrent have those files be treated as directories, but at that point IPFS is going to be much more feature complete; even like, if you have some giant file, on IPFS that might be represented by trees of hashes as opposed to merely a giant array of hashes so you can incrementally and efficiently access the parts you need. So like, while this is awesome work, if you find it _inspiring_ , maybe channel that inspiration into learning about IPFS and extending that ecosystem, rather than doubling down on trying to build on torrent files.

<comment><USER4> Are there any design changes that could create organic adoption of IPFS?

Or, conversely, what design decisions do you think have hindered adoption?

<comment><USER5> I've had a breif look at IPFS, but not enough to say anything with any amount of confidence. That said, the thing that immediately put me off was that everything seemed to want to be browser based, like starting some service that makes a local web server that acts as a GUI - there was even a chrome extension that tried to make this easy for you.

A feature that might exist, but I haven't discovered, that would make IPFS more appealing to me, would be a way to mount the IPFS like it were an FTP server, and navigate it with whatever file manager you prefer and not have to worry about managing the backend stuff.

That is to say, I'd like BTFS for IPFS.

<comment><USER6> It's built into ipfs already: ipfs mount

</comment></comment></comment></comment><comment><USER7> The source code is far smaller that I would've expected, tiny in fact - <USER2> seriously, its probably <2000 lines of actual code and looks extremely simple to audit and fix bugs. It seems the only real external dependency is libtorrent.

Honestly, if your not already amazed if not at the simplicity of this project, than you should be by the simplicity of fuse filesystems and the capabilities it exposes.

<comment><USER8> If you think that's excellent and are interested in fuse, you're probably intereted in 9front which takes the concept to another level. Ftpfs does what it says, but webfs handles http and forms and the like, upas/fs can show your imap inbox, it's splendid and simple and allows your tooling to be the familiar nix-like utilities like awk and sed. Even capture your screenshot by catting /dev/screen to a file

<comment><USER9> Which lib/approach would you recommend if i need run a remote batch process using local files?

For example, on the local system:

remote-execute gcc localfile.c -o localfile.o

And on the remote system, there is a gcc and a remote agent which receives and retransmits the files

<comment><USER8> You would use rcpu(1) which essentially imports the remote cpu. In other words the remote processor "sees" the local file structure/namespace.

9front is full of "free carrots". If you want a remote vpn, just import another servers /net ontop of your process namespace and you're all set.

<comment><USER9> 9front looks so very interesting. Thanks

<comment><USER10> It also stays at "looks very interesting", it's not a usable OS on a normal machine for everyday tasks.

</comment></comment></comment></comment></comment></comment><comment><USER11> This is cool. I can mount most of the Internet Archive as a directory with this. Would love this to grow into what your consumer cloud storage services are but for torrents (a global file system you can mount locally, using torrent data as inodes, with visual representations for availability status similar to the Dropbox green check boxes). Perhaps even with support for web seeding from a storage system of last resort (Backblaze, S3, etc).

<comment><USER12> I know it's not good spirit, but mounting torrents into the filesystem has been done a few times already, there are many projects that do that already.

Also, it's not really advertised, but S3 can act as a torrent node: [https://docs.aws.amazon.com/AmazonS3/latest/dev/S3Torrent.ht...](https://docs.aws.amazon.com/AmazonS3/latest/dev/S3Torrent.html)

<comment><USER11> The cool part is you can have S3 serve a torrent, and then disable access to the object with permissions once it reaches an adequate seed level. You're no longer charged for outbound data, but S3 will continue to act as a tracker for the swarm.

<comment><USER13> Just checked Amazon's S3 page linked to by the PP.

Question - how do the following "Notes" that Amazon has on it's page affect that?

"Amazon S3 does not support the BitTorrent protocol in AWS Regions launched after May 30, 2016."

"You can only get a torrent file for objects that are less than 5 GBs in size."

<comment><USER14> Likely just can only seed/torrent via older s3 regions is all.

<comment><USER11> Blessed be thy us-east-1.

</comment></comment></comment></comment></comment></comment><comment><USER15> Well,

I wrote a device driver for Windows 8 that would mount a .torrent file as a virtual disk way back in 2011. We pitched the intellectual property around to several large companies. The only interest we had in the technology was video game companies... where we could mark file pieces as 'high priority' and allow the player to play the game even when the game disk was partially downloaded.

The IP was sold to a company developing their next-generation console video game system as part of a 24 million dollar package and never saw the light of day. I suspect what they really wanted was the associated patents.

</comment><comment><USER16> I wonder how intelligently this handles piece download order. Torrent clients usually use rarest-first download algorithm, but if you've mounted a movie and you're playing it with VLC, you'd probably want it to download sequentially so there's as little time spent buffering as possible. You could download the pieces on demand (whatever piece the application is trying to read), but I suspect that will provide a suboptimal experience, especially if your download speed is barely above the bitrate of the movie.

<comment><USER8> libtorrent has repeatedly ignored requests for sequential download because of the silly spec. There's a patch out there that quite easily enables it. It's a bit absurd to me because there's a very good use case for sequential download and it's not clear there are any actual side effects.

<comment><USER17> Doesn't sequential downloading degrade the swarm performance?

<comment><USER8> Maybe, but probably less relevant for seeds that are not new. Also if people are streaming via torrents it's a net benefit if all peers have early bits not just random data. In short I do not have empirical evicidence but I do believe the decision to do so should not be made by a library and I also believe the intial assumption that random is better holds true today.

</comment></comment></comment></comment><comment><USER18> Can someone explain why I might use this instead of downloading a select group of files using a torrent file/magnet link? Is the advantage that it selectively downloads files on an as-needed basis? Or, is the product niche somehow related to the fact that the torrent file/magnet link is mounted as a filesystem, instead of only as a collection of files and folders?

<comment><USER19> The latter - it lets you navigate the file structure of a torrent as well as read (stream) file content using any of your usual applications, without having to download the files first.

<comment><USER18> Streaming. I thought about this in the interfile sense, but not the intrafile sense. This makes sense.

</comment></comment></comment><comment><USER20> Okay. I'm afraid to ask. What happens in the case of a) a torrent with no seeders or b) Has seeders with enough data to get a directory listing but either the seeders "drop off" afterwards or are incomplete

Other experiences with network filesystems (CIFS/NFS) on multiple platforms sometimes have things getting hairy if the connection to the server drops while the filesystem is mounted or in use

<comment><USER15> Hi,

A quick glance at [https://github.com/johang/btfs/blob/master/src/btfs.cc](https://github.com/johang/btfs/blob/master/src/btfs.cc) on line 190 reveals that no seeders would result in an infinite wait state: pthread_cond_wait(&signal_cond, &lock);

The author could mitigate this by automatically failing any reads where there are zero seeders and/or if the peer piece map does not contain the block.

</comment></comment><comment><USER21> This is a brilliant concept of a tool. I've never worked with monorepos before, but something like this with rw capacity would be an absolutely amazing pipeline, if every developer in the office and beyond are full nodes in the system.

<comment><USER22> Torrents can't write though, or are you referring to a shared filesystem like NFS?

<comment><USER23> Let's create a chain of immutable blocks with back pointers on top of this to create new versions of the data. Maybe even call it a... blockchain.

</comment></comment></comment><comment><USER24> See [https://github.com/anacrolix/torrent/tree/master/fs](https://github.com/anacrolix/torrent/tree/master/fs) and [https://github.com/anacrolix/torrent/blob/master/cmd/torrent...](https://github.com/anacrolix/torrent/blob/master/cmd/torrentfs/main.go) for a Go FUSE implementation of this. (Looks like it was started in early 2014.)

</comment><comment><USER25> Neat idea, but it seems like abuse of the torrent protocol. If peers don't grab chunks randomly then it partially defeats the purpose of bittorrent.

<comment><USER26> Every torrent client I've used recently has an "enable sequential download" option. The only torrents this would realistically affect are maybe ones where the seeder may go offline when a bunch of clients have been doing sequential downloads and no one has the final parts of the content.

<comment><USER27> Which would be the same as no one would have those random parts.

</comment></comment></comment><comment><USER28> BTFS with mutable torrents would make a nice piracy suite

<comment><USER12> Mutable "torrents" with fuse access exists, it's called hyperdrive ([https://github.com/hypercore- protocol/hyperdrive](https://github.com/hypercore-protocol/hyperdrive)). See the daemon in particular ([https://github.com/hypercore-protocol/hyperdrive- daemon](https://github.com/hypercore-protocol/hyperdrive-daemon))

<comment><USER29> No. Hyperdrive is not like the official BEP-conform "mutable DHT item"-based updatable torrents.

They essentially say "download the most recent version signed by this pubkey", which ia notably distinct from hyperdrive's append-only log.

<comment><USER12> "download the most recent version signed by this pubkey" is literally how hyperdrive works.

The append-only log is hypercore, one of the building blocks of hyperdrive. Hyperdrive is a layer above and gives you a view of how the archive is at any point in time, with preferential access to the latest version.

TBF what I understood from the request of "mutable torrents" wasn't the literal feature, but a way to have decentralized nodes exchanging updatable content. Bittorent with the Mutable Torrents BEP does work, but it's nowhere near as developed as what hyperdrive is _today_. And as sad as it may sound I don't think it will ever be.

<comment><USER29> Yeah. My point was, that BEP 46[0] doesn't have any archive/log functionality.

[0]: [https://www.bittorrent.org/beps/bep_0046.html](https://www.bittorrent.org/beps/bep_0046.html)

</comment></comment></comment></comment></comment><comment><USER30> Tools[1] like this have existed for at least 6 years. Don't know if the older tools still work though.

[1] [https://github.com/mafintosh/torrent- mount](https://github.com/mafintosh/torrent-mount)

</comment><comment><USER31> If you make your own torrent files, how to prevent it accidentally share with the world? Is there anything in the torrent files that can prevent this? (Program and configuration can make mistake.)

<comment><USER24> Yes, there are BEPs that describe not announcing or accepting connections in certain circumstances. There are also peer discovery mechanisms that are designed to work on local networks. Of course none of this matters if you mess up (and someone externally cares enough to take your data), or if your client doesn't support any of this stuff.

</comment></comment><comment><USER32> Why not torrentfs? What are the needs for obfuscation or association with btrfs ('better try remaking fs'? )

<comment><USER33> "Why this project updated yesterday and not the project last updated 3 years ago?"

Unless you mean a different one since you didn't link source

<comment><USER34> Maybe [https://github.com/anacrolix/torrent/tree/master/cmd/torrent...](https://github.com/anacrolix/torrent/tree/master/cmd/torrentfs)?

</comment></comment></comment><comment><USER35> This looks pretty awesome. Does it work with private trackers?

<comment><USER36> Err. Why would it not?

edit: more constructively, this seems to just use libtorrent in the backend, which supports the 'private' flag [https://www.libtorrent.org/features.html](https://www.libtorrent.org/features.html) . Though even if you didn't, it would still 'work' in the sense of being able to download chunks.

<comment><USER37> It also depends on which client ID it exposes and if that one is whitelisted on trackers. But that's not really a technology problem.

</comment></comment></comment><comment><USER38> Cool but can't really see any practical use of this...

</comment><comment><USER39> This is freaking awesome!!

</comment><comment><USER40> Wow, what a great concept.

</comment><comment><USER41> Great stuff, thanks!

</comment><comment> yjftsjthsd-h Well that is neat, albeit an unfortunate name (1-char off from BTRFS). Wonder what performance is like - does it try to preemptively download? Cache? I would expect it to take a while to run `cp ~/mnt_btfs/big_file ~/Downloads/`, but how about `find ~/mnt_btfs`? If it's performant, it could be really nifty:)

<comment><USER42> very unfortunate indeed as there's another project with this name: [https://github.com/TRON-US/go-btfs](https://github.com/TRON-US/go-btfs)

I dont know whether the maintainer is a supporter of crypto (as in tokens) but having a common name with a Tron product (or cryptocoins in general) can backfire.

<comment><USER43> It looks like the BTFS in the OP was the "original", with its first commit in July of 2015. Could be wrong, because the GitHub interface doesn't make it easy to get to the beginning of the 13k commits for go-btfs.

<comment><USER44> 9d0e6a7ffb5deea2c8c8e555d7bf6bcab6fdc6ac 2014-06-26 Big things have small beginnings.

(I have an alias specifically for finding that out)

Personnally, I don't care about any of the crytpo-mining-coining and I think the two are sufficiently distinct.

<comment><USER45> That's when go-ipfs was started - see my other comment for more info</comment></comment></comment></comment></comment>


Tsar Bomba: Largest weapon ever used. - <AUTHOR> http://en.wikipedia.org/wiki/Tsar_Bomba

<comment><USER2> The plane that dropped this bomb would be a larger weapon given a plane can be used as a weapon. Along the same lines aircraft carriers would be the largest weapons I could think of. Though many countries have dabbled into weather modification, then there are gas and other chemical weapons. So is it largest based upon volume or size or weight or it being 100% dedicated weapon? Another historical example beyond those large train driven guns the germans made would be during World War One in which it was common to dig a large tunnel under the enemy fortifications and place tons and tons of explosives under the enemy in which you would eventualy set of blowing up the enemy - [http://en.wikipedia.org/wiki/Battle_of_Messines_(1917)](http://en.wikipedia.org/wiki/Battle_of_Messines_\(1917\)) being a very interesting read in itself involving hundreds of tonnes of explosives. Though like landmines not all got set off and case here [http://rense.com/general47/50000lbWW1bomb.htm](http://rense.com/general47/50000lbWW1bomb.htm) about a 50,000 lbs bomb (22.6796 metric ton), which is still lighter than this Tsar Bomba. Though more background upon such explosive type bombs can be gleamed here [http://en.wikipedia.org/wiki/Tunnelling_companies_of_the_Roy...](http://en.wikipedia.org/wiki/Tunnelling_companies_of_the_Royal_Engineers) and mention is made of a of a far heavier:

""As preparation for the attack, six mines were detonated on 27 March 1916. The largest of these was at St Eloi, dug by the 1st Canadian Tunnelling Company, consisting of 95,600 pounds (43,400 kg) of explosive. This allowed the capture of St Eloi by the British 41st Division.[20] This choice reduced the total explosive to 450 tonnes. The evening before the attack, General Plumer remarked to his staff, "Gentlemen, we may not make history tomorrow, but we shall certainly change the geography." ""

So personaly I'd not say it was the largest or is the largest weapon ever made. But certainly the most scariest.

<comment><USER3> Largest is indeed a misnomer. It is the most powerful.

</comment></comment><comment><USER4> Yes, it's amazing and I look up this stuff from time to time, but (and forgive me if I'm being obtuse and missing the point of HN) why is this standard wikipedia page hacker news?

</comment><comment><USER5> > Designer Julii Borisovich Khariton, _Andrei Sakharov_ , Victor Adamsky, Yuri > Babayev, Yuri Smirnov, and Yuri Trutnev

[http://en.wikipedia.org/wiki/Andrei_Sakharov](http://en.wikipedia.org/wiki/Andrei_Sakharov)

</comment><comment><USER6> Fortunately for a USAF crew the detonation yield was somewhat less than the Soviets planned; a KC-135 had been modified under the _Big Safari_ programme to obtain intel, but strayed so close that the airframe suffered scorching!

One fortunate crew counted their blessings that day...

</comment><comment><USER7> And irony here is that one of the guys, who were developing this thing, was awarded Nobel Peace Prize later.

<comment><USER8> [http://en.wikipedia.org/wiki/Andrei_Sakharov#Turn_to_activis...](http://en.wikipedia.org/wiki/Andrei_Sakharov#Turn_to_activism)

</comment></comment><comment><USER9> Boom goes the dynamite. [http://www.youtube.com/watch?v=W45DRy7M1no](http://www.youtube.com/watch?v=W45DRy7M1no)</comment>


GitHub: Introducing Profile activity overview [beta] - <AUTHOR> https://help.github.com/articles/showing-an-overview-of-your-activity-on-your-profile/ <comment><AUTHOR> Also mentioned in the GitHub Changelog website [1]

[1] [https://blog.github.com/changelog/2018-08-24-profile- activit...](https://blog.github.com/changelog/2018-08-24-profile-activity- overview/)

</comment><comment><USER2> This is cool. I miss when GitHub used to automatically list the open source projects I contributed to without having to pin them manually.</comment>


Show HN: App to summarize news/blog articles and YouTube videos - <AUTHOR> https://www.makemysummary.com <comment><AUTHOR> Founder here,

I built this app to summarize any News/Blog articles or Youtube videos into a few lines of text. It saves me time and attention from having to go through an entire article or video, instead, I can read the summary and decide if an article is worth my time to read further.

The app can be accessed as the website or via Zapier integration for those who are interested in automating their process. I have put in free and paid subscription plans as AI resources are not cheap to operate :(.

I integrated it with Zapier so that summaries can be automatically generated for content originating in from RSS feeds, Emails, Bookmarking software like Pocket, Youtube channels, etc

Looking for feedback!

Zapier users can click here for the beta invite of the integration [https://zapier.com/developer/public- invite/64050/536dc46f726...](https://zapier.com/developer/public- invite/64050/536dc46f72656a0b0e54c881ed5d51d5/)

<comment><USER2> Fantastic! A much-needed tool to build your personal library.

</comment></comment><comment><USER3> Nice project, thanks for sharing. Checked it out on some articles and was quite good!

Out of curiosity - what's the underlying stack?

<comment><AUTHOR> Its a Python-Flask-Gunicorn-Docker base with inferencing using PyTorch/FastAI CNN's and some AWS services. I will release a proper stack diagram in a while.</comment></comment>


Europe Caught in the Cookie Jar - <AUTHOR> http://blogs.wsj.com/tech-europe/2012/05/25/europe-caught-with-its-hand-in-the-cookie-jar/?mod=WSJBlog <comment><USER2> The articles calling this a "Europe" or "EU law" are disingenuous. The EU issued a directive. It's up to the individual countries to implement the directive. So here's what happened:

[http://www.dlapiper.com/files/Uploads/Documents/DLA_Piper%20...](http://www.dlapiper.com/files/Uploads/Documents/DLA_Piper%20_%20How_the_EU_has_implemented_the_new_law_on_cookies.pdf)

Quite a few countries chose an opt-out system, which appears to be workable. Quite a few (most?) countries are still debating what to do or are intentionally or unintentionally dragging their feet (this is very typical).

The UK _chose_ an extremely strict opt-in system, which is complete bullshit and unworkable in practise.

Now, I know it's "de rigeur" for the UK to blame Europe each time something bad happens, but in this case they only have their local government to blame. So please, stop calling this a European problem and tell it like it is: it's a _UK problem_ brought onto them by a stupid government. The sooner the people of the UK realize they have their elected officials to blame, the sooner this can get fixed.

<comment><USER3> As far as I understand it, the UK now allows an implied opt-in, so long as you make it clear to the user that cookies are being used.

<comment><USER2> Do you have a reference for that? I don't see anything like it at the ICO site.

<comment><USER3> Here are some selective quotes from the document, I take it to mean: tell the user with a clear message at least once (ideally get them to click confirm but it's not a requirement):

"In some circumstances those seeking consent might consider implied consent as an option that was perhaps more practical than the explicit opt-in model... For implied consent to work there must be some action taken by the consenting individual from which their consent can be inferred... This might for example be visiting a website, moving from one page to another or clicking on a particular button... The key point, however, is that when taking this action the individual has to have a reasonable understanding that by doing so they are agreeing to cookies being set."

[http://www.ico.gov.uk/for_organisations/privacy_and_electron...](http://www.ico.gov.uk/for_organisations/privacy_and_electronic_communications/the_guide/~/media/documents/library/Privacy_and_electronic/Practical_application/cookies_guidance_v3.ashx)

</comment></comment></comment></comment><comment><USER4> The UK has misunderstood the word "directive" for a considerable amount of time. Maybe it was a translation problem, and it should be reworded to "guidance", since the UK has a very bad habit of applying directives without due consideration. The rest of Europe leaves such directives where they should be, in a box marked, "Good but unworkable ideas. Please archive".

</comment><comment><USER5> This is Europe's way of trying to make users read the Terms & Conditions of every website.

The intentions of the law are good, but I do not believe the approach is that smart. They could have made the companies who own the websites place cookies on the users machines only after they have actually created an account... that seems like consent to me.

</comment><comment><USER6> Can someone explain to me why cookies are something that laws need to be written up about? What's wrong with cookies? What's wrong with paranoid people disabling cookies on their browser and then just granting access to the sites if they need to?

<comment><USER7> The EU privacy legislation is supposed to prevent tracking of people without their consent/knowledge. This is widely considered a worthy goal by consumers.

Fiddling with browser cookie settings is bad because it's opt-out instead of opt-in, opt-out just doesn't work since users have to be technically clueful and spend lots of time and effort on it. Compare to opt-in vs opt-out in email spam.

edit: see [http://en.wikipedia.org/wiki/Data_Protection_Directive#Princ...](http://en.wikipedia.org/wiki/Data_Protection_Directive#Principles)

<comment><USER6> Do cookies track 'people'?

Recently it was determined by courts that an IP address cannot be attributed to a person (in regards to torrents). Why is it different for cookies?

<comment><USER7> The reliability standard for evidence in court cases is a bit higher than what typical cookie applications require.

</comment></comment></comment></comment><comment><USER7> We can hope this will persuade some percentage of sites to abandon cookies, even though the directive ended up pretty toothless.</comment>


How to Leave Facebook (without Leaving Facebook) - <AUTHOR> http://danielhough.co.uk/blog/leaving-facebook-without-leaving-facebook/

<comment><USER2> When I got my new nexus tablet, I didn't install the facebook or twitter app, and I enjoyed using the tablet without feeling the need to keep switching to those apps to check nothing new had been posted. I also removed the facebook app from my phone and it sure does make a difference. If you're in the habit of constantly checking fb/twitter, removing them from your portable devices is an easy way to lessen your habit without cutting yourself off completely. I still have access to fb on my laptop but it's something I check every 2 days or so, rather than something I constantly checked when I was momentarily disengaged.

I find it's lead to me being less sidetracked/distracted when I'm doing something (either when producing work or consuming content)

<comment><AUTHOR> I'm glad this technique has helped for you too. As useful a tool as FB can be, there's really no need for it to permeate every aspect of most peoples' lives, in my opinion :)</comment></comment>