I'm giving up on PGP - <AUTHOR> https://blog.filippo.io/giving-up-on-long-term-pgp/ <comment><USER3> I find very interesting the point about the split between what WoT was supposed to be, in theory, and what little it represents, in practice, in terms of practices about key verification.

It has been said many times that the lack of adoption of pgp in mail was due to the average user not being able to grasp the concepts behind the proper operation for key management, but the article points to common practices among "power users" that will drop the theoretical best practices and switch to fallback, unsecure modes, given the effort needed to properly verify a key binding. If the community that cares about encryption and privacy is not able to routinely verify keys, the whole system definitely has a weak link.

I wonder if pgp is fundamentally flawed, or we have a deep conceptual usability issue here.

And to me, assuming that the most usable thing we can use instead is something that relies on mobile phone identifiers, more often than not tied to a phisical world identity, is really something to worry about.

<comment><USER4> > I wonder if pgp is fundamentally flawed, or we have a deep conceptual > usability issue here.

I don't think the "WoT" is conceptually flawed, and frankly, the argument that "people of average intelligence" can't grasp the concept comes from a very high horse and is also untrue. It's simply that any and all software for PGP utterly fails in the UX and functionality department when it comes to key management.

 _Web of Trust_ implies such a glaringly obvious visual metaphor that I am truly in awe that not a single program works that way.

Tabulations of keys are not a WoT, period.

I don't verify keys one-by-one, that's bullshit. I get one good key that's part of a WoT, and then go from there, and can easily see _from the web structure_ that other keys are good and what their relations are. None of that is accomplished by _any_ PGP frontend.

Instead I get stupid and unhelpful error messages ("no key available" \- I just downloaded it!) and some of the most terrible crypto UI I've seen ("How much do you trust this key? [ ] Not at all [ ] A bit [ ] Fully [ ] Totally" \- w-t-f).

A technical criticism of PGP/GPG is of course also possible. The whole thing is a museum of early 1990s crypto, with default ciphers like CAST5 and messages not being authenticated - and even if the message is authenticated most parts of the PGP protocol are not, meaning that you got that big bunch of C code maintained by that one German guy over there that parses unauthenticated bytes that you shipped through half the internet with a big neon-red sticker on it saying "I'M PGP PLEASE TAMPER WITH ME".

<comment><USER5> I have to partially disagree with that.

Calling PGP an utter failure is an understatement. Just like calling a cat a small tiger.

PGP is possibly the WORST experience in usability for any well known software that ever lived.

This thing should be taught in courses for decades to come as how to fail a product by 1) having no UI 2) no integrations with anything 3) zero usability 4) not even trying to give a fuck about normal users 5) in fact, not even trying to make it possible to use for advanced users.

\---

You want signed email & identities. It's simple.

Just get the national government to distribute RSA USB keys to every citizen. Then they can use them on public government websites (taxes & jobs stuff) to confirm poeple's identities, just plug in the key. Quick and simple. (And that's not incompatible with ALSO asking for a password that was send in a different paper letter. 2FA-style.).

Then later, citizens can sign the emails they send to everyone with gmail/hotmail because they'll add the feature to recognize the national USB identity key, now that there are X millions people using it.

<comment><USER6> > Just get the national government to distribute RSA USB keys to every > citizen.

I lived in a country that did exactly that. And it was a disaster. The keys were trivially easy to steal, even by accident (personal experience here), and you still have the same trust problem as before, except that with a central authority now you do not have as much control.

I have also used the electronic-signature-comes-with-your-ID-card thing, and it was a similar disaster, with dodgy drivers and half-arsed crypto implementations in common software. E.g., try using the same token in Firefox and Thunderbird (or anything else) at the same time.

PGP is fine. It's just that proper security is not easy. And the same applies in the physical world as much as in computing.

<comment><USER7> >The keys were trivially easy to steal, even by accident

So distribute keys on smart cards that don't allow you to export the key. This is what Estonia does, and - concerns about their election infosec aside - <USER2> seems to work pretty well.

<comment><USER6> > So distribute keys on smart cards that don't allow you to export the key

That's what I covered in the second paragraph. :-)

The thing is, both those implementations were a disaster from either a technological or a security point of view. We're not even getting into whether a central source of trust is a good idea or not (you will look at the state of HTTPS and make up your own mind on that). So, to repeat, proper security is hard.

</comment></comment></comment></comment></comment></comment><comment><USER8> The conclusions here (avoiding long-lived per-identity keys and having the option to easily rotate and re-validate per-device keys) are very much what we've aimed for in the end-to-end crypto for Matrix.org ([https://matrix.org/blog/2016/11/21/matrixs-olm-end-to-end- en...](https://matrix.org/blog/2016/11/21/matrixs-olm-end-to-end-encryption- security-assessment-released-and-implemented-cross-platform-on-riot-at- last/)).

Rather than using a silo like Signal or WhatsApp, it _is_ possible to get the flexibility of an open federated network built on an open standard, whilst still having the lighter weight approach of trust common to E2E messaging apps like WhatsApp. Or at least that's the hope :)

<comment><USER9> When I mention Matrix, a lot of people seem to pigeonhole it as a chat system alone because Riot is such a dominating part of the application ecosystem.

It would be really great to have more code and demonstrations available; adding Matrix was suggested for Mastodon[0] to potentially gain chat and private messaging features that aren't part of GNUSocial, but as of right now it's considered out of scope.

[0] [https://github.com/Gargron/mastodon/](https://github.com/Gargron/mastodon/)

<comment><USER8> Hum, just found the bug at [https://github.com/Gargron/mastodon/issues/311](https://github.com/Gargron/mastodon/issues/311) \- shame that folks there haven't grokked what Matrix is. Yes, pigeonholing it as a chat system is kinda missing the point, but it's an easy way to kick the tyres and prove its potential.

Once threading lands in Matrix we'll be adding in gateways for SMTP, IMAP, NNTP, Discourse, and possibly Gnusocial etc - either written by us or from the community. Then hopefully the bigger picture will be more obvious(!)

</comment></comment></comment><comment><USER10> Good points, but also I would like to point out that [https://www.usenix.org/system/files/1401_08-12_mickens.pdf](https://www.usenix.org/system/files/1401_08-12_mickens.pdf) linked from the blog post was an entertaining read so for anyone that didn't read said PDF, do.

<comment><USER11> > "But James," you protest, "there are many best practices for choosing > passwords!" Yes, I am aware of the "use a vivid image" technique, and if I > lived in a sensory deprivation tank and I had never used the Internet, I > could easily remember a password phrase like "Gigantic Martian Insect > Party." Unfortunately, I have used the Internet, and this means that I have > seen, heard, and occasionally paid money for every thing that could ever be > imagined. I have seen a video called "Gigantic Martian Insect Party," and I > have seen another video called "Gigantic Martian Insect Party 2: Don't Tell > Mom," and I hated both videos, but this did not stop me from directing the > sequel "Gigantic Mar- tian Insect Party Into Darkness.

This is hilarious, thanks for pointing this out!

<comment><USER12> I like:

"It's like, websites are amazing BUT DON'T CLICK ON THAT LINK, and your phone can run all of these amazing apps BUT MANY OF YOUR APPS ARE EVIL, and if you order a Russian bride on Craigslist YOU MAY GET A CONFUSED FILIPINO MAN WHO DOES NOT LIKE BEING SHIPPED IN A BOX. It's not clear what else there is to do with computers besides click on things, run applications, and fill spiritual voids using destitute mail-ordered foreigners. If the security people are correct, then the only provably safe activity is to stare at a horseshoe whose integrity has been verified by a quorum of Rivest, Shamir, and Adleman."

For his claim "YOU'RE STILL GONNA BE MOSSAD'ED UPON" I still don't know how to interpret the fact that Snowden seems to be relatively fine. Maybe that he had the idea about the blind spots of the system in which he worked.

His opinion on PGP "web of trust":

""Chains of Attestation" is a great name for a heavy metal band, but it is less practical in the real, non- Ozzy-Ozbourne-based world, since I don't just need a chain of attestation between me and some unknown, filthy stranger— I also need a chain of attestation for each link in that chain. This recursive attestation eventually leads to fractals and H.P. Lovecraft-style madness."

It is an opsec problem that all the connections are then cryptographically provable.

<comment><USER4> > For his claim "YOU'RE STILL GONNA BE MOSSAD'ED UPON" I still don't know how > to interpret the fact that Snowden seems to be relatively fine. Maybe that > he had the idea about the blind spots of the system in which he worked.

What reason would any agency have to un-live Snowden? Any damage he has done was already done in HK and before; he has nothing more to reveal. It would only turn public opinion against the agencies.

<comment><USER13> True that it would hurt public opinion even further of the agencies if they were to take him out - but I thought he only revealed a portion of what he grabbed.

<comment><USER4> My understanding is that he handed everything off to the journalists.

<comment><USER14> Yes, for precisely the reason that he did not want to be the arbiter of what is released. That's probably why he's still alive. It was a good decision

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> > Yeah, about that. I never ever ever successfully used the WoT to validate a > public key.

If you ever installed a Debian package then you did. A long-term identity as "Bob Jones" might not be terribly useful - but that's not the kind of long- term identity we care about a lot in real life either. A long-term identity as "Debian release manager" or "Signatory on bank account xyz" or even "Wikileaks committee member" is a lot more important, and for those cases PGP becomes very useful.

> Then, there's the UX problem. Easy crippling mistakes. Messy keyserver > listings from years ago. "I can't read this email on my phone". "Or on the > laptop, I left the keys I never use on the other machine".

These are real problems. We should fix them. But we don't need a new crypto standard to do so! It never fails to amaze me how many people/organizations are like "I don't have the time/money/patience to write a high-quality OpenPGP libary (or a high-quality GPG frontend), but I'm perfectly placed to create a new cryptosystem from scratch."

> Your average adversary probably can't MitM Twitter DMs (which means you can > use them to exchange fingerprints opportunistically, while still protecting > your privacy). The Mossad will do Mossad things to your machine, whatever > key you use.

This is pets vs cattle in the opposite direction. Can Mossad Mossad you personally? Yes, if you're a big enough target, but they can't Mossad everyone. Whereas the NSA can MitM key fingerprints exchanged via Twitter on an industrial scale.

> Mostly I'll use Signal or WhatsApp, which offer vastly better endpoint > security on iOS, ephemerality, and smoother key rotation.

If you're using iOS you've already given up against state-level attackers. Anything actually encrypted (e.g. IRC with SSL) is more than adequate in that case. Most people don't need the jump up to PGP, sure. But it's important that the option is there for people that really do need it. It bears repeating that we know, from their complaints in leaked emails, that the NSA can't break PGP when used correctly. That's an extremely strong seal of approval for the most critical use cases for encryption.

<comment><USER16> _> If you're using iOS you've already given up against state-level attackers._

Wasn't the recent apple vs FBI debacle evidence to the contrary?

<comment><USER17> It ended because FBI just cracked the device anyway. How is it contrary?

<comment><USER18> Insofar as that the FBI has to actually crack the device and don't have universal key of some sort. Newer version will (and already are) more secure. Its not perfect because this was 'just' the FBI and 'just' the legal way, but at least its something.

</comment></comment></comment></comment><comment><USER19> PGP may have broken down for the author, but it's still used _in a lot of places_. For example, to communicate with our bankers at work, every email has to be properly encrypted and signed - or it goes into a blackhole. The only way to exchange public keys(initially) is in person. Once that is done, new keys are provided from that person, and the WoT expands.

tldr; it doesn't work for the author, but it _does_ work for lots of individuals and even more companies with secrets to protect.

<comment><USER20> PGP is also used very heavily on darknet on drug marketplaces.

OTR (or even Signal) is not possible there, so people stick to good-and-tried PGP.

<comment><USER21> I think darkweb marketplaces are a slightly different use case though. The requirements for a darkweb transaction are the ability to tell the vendor your address so they can send you illegal goods, while hiding it from the marketplace itself in case their servers are seized. A random PGP key with no real name and no verification is entirely adequate for this purpose - indeed, any kind of identity validation would probably be seen as a negative for such a situation.

</comment></comment></comment><comment><USER22> Summary: The author decided that being connected to long term keys does more harm than good, partly due to the pressure to stay with potentially compromised keys due to the difficulty of starting over. The author will instead focus on secure IM using short term keys bootstrapped by social media accounts.

1) As others have pointed out, I really think the author is overestimating the effort required to compromise a twitter or other social media account. There are many accounts of this happening, including to people like Brian Krebs who knows he is a target and does everything possible to avoid the attacks.

2) Encrypted IM as the primary higher security communication channel seems to be a popular option these days, mostly leaving those of us who don't like IM to look at alternatives.

3) Briar (briarproject.org) is a promising alternative for messaging, although not ready yet and currently only targeting android, which has its own major security issues. Due to the focus on enabling offline, forward secure messaging, it can be used to defeat mass (network) survailance. It can also be used online and addresses some of the specific concerns raised.

4) General purpose computers are both handy and necessarily have security issues. Special purpose devices for more limited secure communication would help with many issues.

5) Secure communication isn't much of a goal; it is more helpful to consider specific threats. If you do something non-trivial towards a vague goal, it is easy to find a way it doesn't meet that goal when you feel like not doing it any more. I'm not sure what the author was trying to achieve with PGP in the first place.

<comment><USER23> Kind of off topic: I really like iMessage. Not to be an Apple fanboi, but it really is one of those things where It Just Works(tm). Encryption shouldn't have to be something the end user has to worry about; it should be transparent to the user while still being as secure as possible (HTTPS and TLS are a great example of this). For the user who cares about encryption, they don't have to configure anything. For the user that doesn't care, they still benefit.

By baking it into the OS, Apple ensures that anyone with an iDevice benefits from it. Compare that to having to download an app that may change depending on possible compromises. Anyone who's tried to convince a family member to use Signal, Telegram, etc. knows how much of a pain it is.

<comment><USER24> > By baking it into the OS, Apple ensures that anyone with an iDevice benefits > from it.

But _only_ people with iDevices benefit from it. I prefer Signal to iMessage _because_ iMessage is iOS only, and I'm disappointed with Google for not including an iMessage equivalent with secure messaging by default.

> Compare that to having to download an app that may change depending on > possible compromises.

If you mean what I think you mean, using iMessage will not save you/them from this any more than using Signal would, the only benefit to iMessage is that it's already installed on iDevices when you buy them and has secure-messaging enabled by default.

Which is still a step above Android currently - which has no default-installed secure messaging app _at all_.

I'm lookin at you Google!

</comment></comment></comment><comment><USER25> To me, Keybase ([https://keybase.io](https://keybase.io)) seems to solve the "PGP has a bad user experience" problem correctly for like 90% of the population. You post proofs of your public key to known media (Twitter, Github, your website, etc.) which you control. These can be checked by anyone.

Even if the remote person doesn't know they are talking to you (as a human entity), they know they are talking to the _combined online persona of all those accounts_ , which is all that matters for the vast majority of them. Yes, it is possible for all these services to collude and post false proofs, but that would be relatively easily detectable, and realistically not a concern for the majority of people out there, whose alternative is to not use _any_ encryption. People who are really concerned can always fall back to standard PGP.

[Edit: Looks like I didn't read the article carefully enough, the author himself says he actually does use Keybase too.]

<comment><USER26> The combined online persona of those accounts is only as strong as their combined security. aka: Why would services need to collude when they can get the job done by ineptitude?

[https://medium.com/@N/how-i-lost-my-50-000-twitter- username-...](https://medium.com/@N/how-i-lost-my-50-000-twitter- username-24eb09e026dd#.ap51boulz)

<comment><USER25> I agree, a lot of services displayed a shocking amount of incompetence in that post. However,

a) The more proofs you have, the harder it becomes to force them. YC for example is one location, and is run (in my opinion) by very smart people where it would be hard to get a compromise.

b) My point is that this is an excellent alternative to not using anything in a way that is both friendly to people ("just make this post on [website]") and compatible with an older, better method of privacy (PGP) that people have been using for years.

It may not be as perfect as some of the more esoteric alternatives that people have suggested elsewhere in the thread (I'm not sure about this, can an incompetent phone company employee compromise some of the phone-based ones? I've come across a lot of incompetent phone company people), but much easier for the regular person to use.

</comment></comment></comment><comment><USER27> People who use PGP keys, can you give examples of your use? I'm genuinely curious. Who are you contacting, or who is contacting you? The author says he only receives 2 encrypted emails a year. Not only do I not have a PGP key, I don't think I've ever found myself in a situation where it was even an option to use one.

<comment><USER28> \- All internal company emails. \- Mailing Lists

Side note: using pgp with MacOs Mail is super easy [https://gpgtools.org/](https://gpgtools.org/) (the project is currently working on Sierra support)

<comment><USER29> Super easy until you upgrade your operating system and suddenly you can't use your mail client for months while the understaffed open source project is trying to reverse engineer whatever Apple changed...

<comment><USER28> Yeah... definitely not the best experience. But it's free software so I'm not going to complain.

I have been using enigma on thunderbird in the meantime, which makes me appreciate how well the native mail app functions.

Can't wait for that fix.

<comment><USER29> Sure, if anything I'd complain about Apple's mail client being closed source and incapable of PGP.

</comment></comment></comment></comment></comment><comment><USER20> I will add what I wrote on a different thread

PGP is used very heavily on online drug marketplaces. You really can't use Signal or WhatsApp there - leaking too much metadata - and even OTR is leaking too much data.

PGP is quite good for this, and people use it for encoding their communication.

</comment><comment><USER30> I've been thinking a lot about PGP and other encrypted messengers lately. It's incredibly hard to get a lot of people to agree on one messaging app besides default SMS. I wish there was an open source suite of tools for mobile/desktop that easily layered PGP on top of SMS/email experience and would fall back in the absence of keys. Perhaps bluetooth for swapping keys with friends. It's something that needs to be seamless enough that the end user can't tell the difference. I don't think messaging encryption will achieve mass adoption until something like that is built or built into mobile OS's.

<comment><USER31> Carriers would need to change the way they handle SMS, and everything a carrier does is subject to state regulations. And states seem to like clear text.

<comment><USER30> Why's that? I understand the message would increase in size because of the encryption, but I think it would be technically feasible now. Didn't even apple just introduce encryption into their messenger? My issue with apple's encryption is it's closed source and apple only.

<comment><USER32> iMessage end-to-end encryption is not a recent introduction. It has been in place for several years, though I can't find the exact iOS version it was introduced in.

<comment><USER30> Recent to me is the last few years, technology-wise. Your timeline may look different.

<comment><USER32> Fair point. We are talking about a 5 year old product though...

</comment></comment></comment></comment></comment></comment><comment><USER33> I have given up on the "web of trust" a long time ago for most of the reasons the author states. I think in order to work PGP would need to reach a critical mass of users that seems totally out of reach at the moment. Maybe if Google or Facebook starts issuing mandatory PGP keys linked with each account or something like that. Not sure why they'd want to do that though.

That being said there's still a lot of good and useful in PGP even if you ignore the WoT completely. I use it to secure my passwords, log into remote servers securely with SSH and I sign all of my emails with it, which is probably useless 99.9% of the time but at least it can be used in retrospect to prove that I did write those messages. I can also use it to sign git tags so that my code can still be trusted even if there's a breach in, say, github. I have a rather vast choice of GnuPG tokens I can purchase if I want an added layer of convenience and (hopefully) security.

Sure, WoT is simply unusable currently unless you're communicating mostly with hardcore PGP enthusiasts. That won't be enough to make me give up on PGP.

</comment><comment><USER34> One perfectly valid way so solve the web of trust issue with PGP is to simply ignore the web of trust issue with PGP. Just stick your pubkey on your website and you are done. You just understand that there is a very low chance that any encrypted email from an unknown entity is actually from a composite entity. If you think that you are of interest to entities that have the ability to MITM your pubkey, you might want to mention the problem to potential unknown email senders as a disclaimer on your web page. In practice an entity with the power to MITM pubkeys is not going to use the facility unless they are really really sure as they are eventually going to get caught at it.

Things like Signal and Whatapp don't solve the web of trust issue either so you are not any worse off by using the head in the sand approach.

</comment><comment><USER35> Years ago I worked with a guy who literally wrote a book about how to use PGP. I asked him if he could help me set it up and he said "I don't use it, it's too hard."

<comment><USER36> It's not too hard, at least not on Linux and for anyone with some familiarity with the terminal. Getting started can be done like this...

Install GPG:

      sudo apt-get install gnupg

Generate a key:

      gpg --gen-key

Export your public key as ASCII text and then post it somewhere publicly:

      gpg --armor --export $your_uid > your_public_key.gpg

Import my public key:

      gpg --import my_public_key.gpg

Verify my key by viewing my fingerprint (type _fpr_ ) and confirming it with me, then sign it (type _sign_ ):

      gpg --edit-key $my_uid

Encrypt the file message.txt and then send message.gpg to me via any medium:

      gpg --output message.gpg --encrypt --recipient $my_uid message.txt

Decrypt my response to you:

      gpg --output response.txt --decrypt response.gpg

I know that's pretty complicated for an average user, but it's not harder than any of the day to day work that we do as programmers. I have not used GPG in years though since my deep web adventures, so hopefully I didn't mess anything up and prove the point that GPG is too hard!

</comment></comment><comment><USER37> I use MacGPG to sign commits on GitHub but I have to admit that the E-mail portion has fallen by the wayside. (The last time I really used it was to E-mail a professor of a cryptography course for an assignment!)

While I also don't know many people that use this for E-mail, it doesn't help that virtually every OS update in the last 5 years has consistently broken it, taking sometimes months for a fix.

For those reasons, this needs to be baked into the OS to be viable. Only when somebody like Apple can install it _by default_ , and _make sure_ it works between updates, will it have the reliability and widespread availability that is necessary for success.

</comment><comment><USER38> After all that, he was only getting two encrypted emails a year! Damn. That's crazy.

<comment><USER39> This has been my experience. The only "good" experience I've had with encrypted messages through email was a back and forth exchange I had with a fellow Keybase user where I manually copy and pasted blocks of encrypted text into/out of their web interface.

<comment><USER40> From my experience - the only PGP users I've spoken to were all on Keybase or interested in a Keybase invite. It was about 6 people for the entirety of last year - and 3 people this year...it certainly has a problem of "almost nobody uses it" but Keybase seems to have eased things slightly - or at least made it easier to discover people who also use PGP.

I see the two problems being "People don't bother with the clunkiness of using PGP when sending an email about what to pick up from the store" and "most users have no reason to talk to most other users".

I'm considering making it a point to message people with interesting Keybase avatars or social profiles tied to their Keybase if only to have an excuse to use PGP more, as silly as that might sound.

<comment><USER18> Keybase has clearly moved away from PGP. They want to use Saltpack whenever possible, NaCl based encryption. They want to solve the problem of multiple devices and not having to share the private key between all of them.

As far as I know they are working on a messaging app as well.

<comment><USER41> I admit my ignorance of saltpack and keybase's implementation of it, but don't they propose storing the key for you? That seems to create a trust issue, which is precisely what the author is complaining people don't pay attention to, trust.

On the other hand, perhaps the argument for this would be a "trusted 3rd party" model (a la S/MIME).

<comment><USER18> Well, you can have your GPG Private Key online if you like, but thats not my point. The new system moves away from having any sort of master key.

Rather every device has a new key, and they all sign each other. You can add new devices without old proves being invalidated.

See: [https://keybase.io/blog/keybase-new-key- model](https://keybase.io/blog/keybase-new-key-model) and [https://saltpack.org/](https://saltpack.org/)

I would really like a solution using this stuff that is highly integrated with my mail client.

<comment><USER41> That's an interesting solution. Rather than having keybase keep your key, your devices are communicating directly to validate each other? I'm going to have to review this in more detail, thanks.

<comment><USER18> Currently you have to use a paper key to do it. You then upload a public prove chain. Its not where it should be yet, but the concept is pretty good.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER42> Usability is the "key" \- it's hard enough to get people to use signal ("why do I need another messaging app?")

<comment><USER31> If they don't have Signal you could get them to either use Whatsapp, or only use the encrypted conversation feature of Facebook's Messenger.

They should have one or the other already installed if they're complaining about "another messaging app".

<comment><USER43> This works fine until you get someone who only uses iMessage, and you use Android.

<comment><USER44> Exactly what finally convinced me to add whatsapp.

</comment></comment></comment></comment><comment><USER45> How is the author so seriously involved in PGP and only receive two encrypted emails a year? I'm basically just a dude who uses PGP because it's cool and I get tens of them. You just need one friend who also thinks it's cool.

<comment><USER46> Even Zimmermann, PGP author, has given up as this journal says [https://www.scmagazine.com/phil-zimmermann-doesnt-encrypt- em...](https://www.scmagazine.com/phil-zimmermann-doesnt-encrypt- emails/article/532484/)

<comment><USER40> A rather large misrepresentation of what was actually said.

 _> Zimmermann later clarified in a Motherboard article that PGP, acquired by Symantec in 2010, isn't compatible with his MacBook, and the technology never worked with any iOS device._

</comment></comment></comment><comment><USER47> Dark Mail seems to be dead. Are there any efforts to make e-mail secure by default and e2e encrypted?.

<comment><USER48> Most interesting e2e projects have abandoned email, specifically SMTP, as a secure messaging platform. I would look outside SMTP-based solutions if I were to start using a different project (assuming doing so is an option... I hope it is!).

My recommendation here is Signal: [https://whispersystems.org/](https://whispersystems.org/)

<comment><USER49> Signal is nice, and I use it. But it's an instant messaging system. Email has different use cases.

I think what we're going to need is a new, non-SMTP protocol, which preserves all of the good things about email, while providing e2e encryption and (pseudonymous) identity assurance. I don't know enough to be involved in designing that protocol, though, other than saying what I want to see as an end-user.

<comment><USER48> What properties does email have that asynchronous messaging services (e.g. Signal) do not?

<comment><USER50> Cross-platform (Chrome web-apps don't count), Federated, Distributed, to name a few. The reason email is so entrenched is probably because of these reasons entirely. Being able to send a message from any provider to any provider certainly helped spread adoption easily.

</comment></comment></comment></comment></comment><comment><USER46> > I never ever ever successfully used the WoT to validate a public key.

TOFU, anyone?

From: Werner Koch wk at gnupg.org

Date: Fri Dec 4 14:06:49 CET 2015

Subject: [Announce] GnuPG 2.1.10 released

Hello!

The GnuPG team is pleased to announce the availability of a new release of GnuPG modern: Version 2.1.10. The main features of this release are support for TOFU (Trust-On-First-Use) and anonymous key retrieval via Tor.

...

</comment><comment><USER51> "Yubikeys would get exposed to hotel rooms."

Can someone please elaborate on this?

<comment><USER52> I took that to mean he left it in a hotel room while going somewhere, exposing it to any number of maids, possibly including those of a malevolent nature.

<comment><USER51> As far as I understand, it is not possible to extract a private key from a Yubikey [1]

[1] [https://www.yubico.com/2012/12/yubikey-neo- openpgp/](https://www.yubico.com/2012/12/yubikey-neo-openpgp/)

</comment></comment></comment><comment><USER53> I think his security threat model was _nation state_ when he really needed _APT_ , annoyingly persistent teenager. There are elements of what he did that I'd do if they were automated. But if the NSA, Mossad, Hacking Team want to get me, they're going to get me. And it would only be vanity to say they are even thinking of me.

So this is the perfect being the enemy of the good. I need good privacy and good security. I'm not going to torture myself for perfect privacy and perfect security. Cut to the last scene of _The Conversation_ where Gene Hackman's character tears apart his office ripping down the walls to find the bug and the eavesdropper taunts him. Who is torturing whom?

</comment><comment><USER54> Yeah. A friend of mine said it best: "if there is a conflict between convenience and security/privacy/anything else, convenience always wins." PGP didn't stand a chance.

</comment><comment><USER55> gpg is promoted as a kind of swiss army knife of privacy, but its interface always puts email first. If you use it for something else, you must paranoidly guard every command so that it doesn't by mistake publish information about your privately used keys, for example.

<comment><USER15> Very true. A high-quality library (that was actually built as a library) for OpenPGP would be a very valuable thing to have.

</comment></comment><comment><USER56> Who here is using keybase to manage your public key being distributed? It seems like a great idea since your key is tied to your online identity

<comment><USER57> Keybase is great for managing my keys, but I haven't found any services that make it easy to natively use them. They've sat unused for the ~2 years I've had a Keybase account.

That said, I have about 25 invitations. Anyone want one?

Edit: Not true. I used my keys once to sign a GitHub release for a novelty project nobody uses.

</comment></comment><comment><USER58> The #1 problem, beyond the usability issues, is that most users still just do not care. They are willfully ignorant (a mentality which is actively celebrated these days in some influential countries), and cannot be convinced in the value of privacy or security.

I have tried without much success to get people to move to ProtonMail. I have tried without much success to get people to move to Wire messenger. (And incidentally, the author mentions Signal and WhatsApp... I wonder why he doesn't use Wire?)

So without consumers who care, the only audience for PGP and other security focused tools are the geeks who too easily tolerate bad interfaces.

</comment><comment><USER59> Me too. The reason I gave up on PGP is I couldn't find anyone that would willingly use the service through email. With Signal I can find people that use it.

</comment><comment><USER60> I've been using PGP for mostly 1 year and yes, I agree. I still send around signed email, but never received one encrypted so far. Generating keys and backing them up is tricky and I have probably made mistake in generating or storing them at some point in time. Is there a step-by-step good-practice on how to use PGP?

</comment><comment><USER61> I gave up 3 years ago: [http://blog.mostlydoing.com/2014/03/how-to-securely- store-pr...](http://blog.mostlydoing.com/2014/03/how-to-securely-store- private-keys.html) (I don't trust myself to securely store my private keys)

</comment><comment><USER18> I feel the pain as well. I'm not ready to make the same jump however.

I really do support Keybase, there I see the potential to solve many of the issues. I would love some better integration into the E-Mail ecosystem, but sadly its not there jet, and its not there focus.

</comment><comment><USER62> My ongoing concern is around where reasonable alternatives fit in.

\- Securedrop, where users upload messages and they are automatically encrypted

\- Darknet services

\- Businesses where users communicate via desktops.

Signal/ etc works in a different space and doesn't provide an alternative to these.

</comment><comment><USER63> There isn't a lot to unpack in this article. Most is set-up; explaining how connected he is to a community that is enthusiastic about PGP yet doesn't apply secure operations in practice.

Then there is the main complaint:

> I haven't done a formal study, but I'm almost positive that everyone that > used PGP to contact me has or would have done (if asked) one of the > following:

> \- pulled the best-looking key from a keyserver, most likely not even over > TLS

> \- used a different key if replied with "this is my new key"

> \- resent the email unencrypted if provided an excuse like "I'm traveling"

I haven't done a formal study either, but no one I know that uses PGP would do any of these things under any circumstances. PGP works fine for myself and the group of people I know that use it, because we adhere to security protocols that are just as important -- if not more -- than using PGP itself.

<comment><AUTHOR> That is definitely not my main complaint, and I suspect it might have caught your eye because it's the one that wouldn't apply to you (which is absolutely possible).

The article is about the flaws of long-term identity keys, and it would stand even if there weren't UX, adoption, or security protocols adherence issues.

Maybe try to unpack a bit more :)

<comment><USER63> You're right, long-term identity keys are bad. Long-term identity keys are not a concept mandated by PGP, they are a result of how people use PGP or how PGP is implemented in a third party app.

No part of PGP requires you to use a key more than once. This phenomenon is a result of a consensus of people deciding on a terrible operations strategy over a long period of time.

Edit: this comes to mind [https://gist.github.com/grugq/03167bed45e774551155](https://gist.github.com/grugq/03167bed45e774551155)

<comment><AUTHOR> Agreed, I link to that Gist exactly in the "Moving Forward" section ;)

<comment><USER63> I must have missed that.

I don't understand what the point of your blog post is, in this case. You understand why PGP is needed and how it's important, how to use it correctly, etc, yet you "give up" on it because no one you know uses it correctly.

Is that it?

By the way, how are you going to send someone a 5GB file securely using Signal?

<comment><USER64> Encrypted in any way, hosted anywhere safe, sending the passphrase via Signal, done.

</comment></comment></comment></comment></comment></comment><comment><USER65> ?What experiences have folks with ZixMail [https://www.zixcorp.com/why- zix/email-encryption](https://www.zixcorp.com/why-zix/email-encryption)

</comment><comment><USER66> "One click encryption is one click too many" \- Bruce Schneier

</comment><comment><USER67> On a related thought, using a 'secure' (or so they say ?) email provider à là protonmail is just secure if you send your email to another protonmail user.

Problem with services like that is they omit to tell their users that email is not E2E, and sending from protonmail to gmail will just disable the benefits of using protonmail.

So yes, if you are trying to send encrypted email to a GMAIL user, your only way is to use GPG. Or to get them onboard of protonmail and the likes. It's... impossible.

<comment> j-conn When sending to a non-protonmail account, you have the option to encrypt the message contents-- recipient has to open a link and enter the password. I think decryption is done in the browser in that case too (not 100% sure tho)

<comment><USER68> That is correct. The recipient can reply from that webpage as well, however you can't have a conversation there (your replies to their replies don't show up in that page, they have to get new URLs in their email).

</comment></comment></comment><comment><USER69> The proposed solution is to use Twitter to use Signal or Whatsapp. This forces your correspondents to use one of these centralized services, and also to run proprietary software to be able to use them.

I'm also irritated by GPG and OpenPGP's shortcomings, but it still gives people a way to contact you with reasonable security and without having to use specific proprietary services.

</comment><comment><USER70> There was not a single mention of CA-signed S/MIME certificates. That seems quite an oversight.

</comment><comment><USER71> Never heard of yubikeys, pretty cool. Thanks.

</comment><comment><USER68> So, to distinguish, there's web-of-trust things and general pgp/gpg encryption (and signing) UX. Both of these are pretty abysmal for non-technical users.

I don't think "muggle" users would be interested in the web of trust at all, and I doubt they can really handle it all that well. But I'm a pretty technical person (MS in Computer Science, PhD in a different field), and well:

[http://keyserver.ubuntu.com/pks/lookup?op=vindex&search=eric...](http://keyserver.ubuntu.com/pks/lookup?op=vindex&search=eric+eslinger&fingerprint=on)

I don't think the web of trust really matters- would you look at that and say, "hey, this Eric fellow has a 2004 key for his gmail, and an unrelated 2016 one, I'd better not trust him." Doubtful.

Honestly, in today's internet (I know, dangerously political...) I think there should be a stronger move toward broad-spectrum encryption of all emails. I actually generate trust with most of my email correspondents independently, but I sure would like to encrypt my communication. Signal is good for shorter messages, but email is still email.

It isn't like I have state secrets in my email, but I _do_ have stuff I don't want random government snoops reading, especially if they're bulk-collecting. Furthermore, I think it's important for more people (even people who don't need it) to encrypt their correspondence, so we can provide cover for people who really do need it. Journalists and dissidents won't stand out as much if everybody is encrypting.

To that end, I think pgp / gpg is still pretty cruddy for UX. There are decent solutions for each platform, but nothing really _good_ , and my friends / family aren't likely to use a mail client or webmail that's not at least almost as good as gmail/inbox just because I am worried about privacy.

I've recently moved to protonmail for most mail, since it has a very slick user experience and I want to know it well enough to be able to recommend it to other people. However, protonmail doesn't let me have my private key (or its analogue - I'm not 100% sure how things really work, but I have a public key that I can give to other people, and those other people can send me encrypted stuff from off-platform. I just can't reply in the same fashion). That means if I lose my protonmail account, woops, I can't read the emails you sent me encrypted to my @protonmail.com account, even if I get the emails. This is more of A Thing now that you can set up protonmail as your MX, and therefore get emails addressed to domains you control on the platform - if I ever swapped my personal domain around, I'd like to have the key.

So, for end-to-end encrypted simple messages, signal is great. I just wish protonmail did interop, and then I'd really recommend it to other people.

</comment><comment><USER72> I guess this is a good opportunity to review Matthew Green and Moxie's posts on PGP, too:

[https://blog.cryptographyengineering.com/2014/08/13/whats- ma...](https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with- pgp/)

[https://moxie.org/blog/gpg-and-me/](https://moxie.org/blog/gpg-and-me/)

<comment><USER73> I really like what moxie wrote here. There is a big difference from the best thing and the thing that can actually exist in the real world right now.

</comment></comment><comment><USER74> The 'deficiency' of PGP lay in the leaky nature of the computer itself. How do you maintain your all important private keys? On disk? In memory? USB? All are leaky from the get go. And this, I posit, is the problem gents.

</comment><comment> torrent-of-ions Why is WhatsApp trusted? Isn't it proprietary and controlled by Zuckerberg? What am I missing here?

</comment><comment><USER75> 9/10 end users just don't understand that security and convenience are inversely related.

<comment><USER76> Systems like Signal and WhatsApp show that that's not necessarily true to the degree of previous solutions.

<comment><USER45> I think that the analysis is a little more involved than that. Roughly, I'd say that at any given point you can make "trivial" tradeoffs between security and convenience. However there can be some groundbreaking advances in one that don't cost you on the other. And then that point you may be able to do a "trivial" rebalance if you'd like.

</comment></comment></comment><comment><USER77> it is mainly the tools that are blamed even in this post.

nobody wants to make a better sks keyserver or gpg cli. why? because you dont get no fame or money from it.

filippo show me your gpg commits.

</comment><comment><USER78> What's this? But seriously what is this? I use GnuPG and am quite fond of it. I've a pubkey.asc up my website, and I use gpg to encrypt some files and my backup tarballs. PGP is not a mail tool, it's for encrypting strings. Yhis guy does not know what it is and cries for having done much ado for nothing. Key signing parties? I certainly have better things to do. Just generate a key and put it on mit key server, call it done.

And he complains he don't get encrypted mail. So what, I'd rather be happy. It'll be useful when it'll be w/ email, and has many other uses otherwise.

<comment><USER79> He clearly knows what it is. He isn't ranting against PGP he is ranting against the WoT. If you got an encrypted email from Linus Torvalds, how would you verify it was him?

[https://news.ycombinator.com/item?id=12296974](https://news.ycombinator.com/item?id=12296974)

<comment><USER78> I wouldn't. If I'm going to get an encrypted mail from someone, I've alread verified the sender.</comment></comment></comment>


Zcash, an Untraceable Bitcoin Alternative, Launches in Alpha - <AUTHOR> http://www.wired.com/2016/01/zcash-an-untraceable-bitcoin-alternative-launches-in-alpha/ <comment><AUTHOR> Here's a link to Zcash's first blog post on their official site:

[https://z.cash/blog/helloworld.html](https://z.cash/blog/helloworld.html)</comment>


Apple rejects Valve's Steam Link game streaming app over 'business conflicts' - <AUTHOR> https://www.theverge.com/2018/5/24/17392470/apple-rejects-valve-steam-link-app-store-ios-game-steaming <comment><USER2> People who go on and on about the Google and Amazon "monopolies" \-- which only _benefit_ consumers with low prices and expansive services -- this is what actual monopolistic behavior looks like. Apple controls access to a significant share of the mobile application industry and it directly abuses that market power to harm customers by reducing competition and artificially raising prices. Apple is being sued in both US and French courts over it appstore monopoly so let's hope this ridiculous practice is stopped soon.

<comment><USER3> An example of monopolistic Google behavior was when they refused to make a YouTube app for any Windows platform (Win8, and later Win10) - which is fine - but then they also blocked the app that Microsoft itself has developed. Because they control access to YouTube as a service, they could do that. And because YouTube is _the_ place for videos on the Net, it hurt the platform pretty bad.

<comment><USER4> _Despite the two companies collaborating on an app based on HTML5, Microsoft 's app is still breaking YouTube's terms of use._

 _" Microsoft has not made the browser upgrades necessary to enable a fully- featured YouTube experience, and has instead re-released a YouTube app that violates our Terms of Service - It has been disabled. We value our broad developer community and therefore ask everyone to adhere to the same guidelines"_

[https://www.theverge.com/2013/8/15/4624706/google-blocks- win...](https://www.theverge.com/2013/8/15/4624706/google-blocks-window-phone- youtube-app)

My impression was Microsoft being arrogant. Besides, Windows 8/10 users could still access YT via web.

<comment><USER5> Google intentionally ignores issues Edge/IE users have with their products because they want them to switch to Chrome. This isn't an issue of Microsoft making "browser upgrades", it's an issue of Google developing to and supporting Chrome and ignoring the rest of the web.

<comment><USER6> I don't blame anyone if they don't want to support Edge/IE. Microsoft's browsers are horrible to develop for. Personally I'd be much happier if more of my users would switch to Chrome.

<comment><USER7> I haven't tried to write extensions for Edge or anything like that, but have you recently developed for Edge or even IE11? I've run into a few minor warts (minor as in a 5-minutes fix) with IE11, but it's been smooth sailing with Edge. Mobile FireFox has comparatively been a nightmare in spite of MDN's wonderful docs.

<comment><USER5> Edge extensions use the same new standard as Firefox, it shouldn't be that bad.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Here's the feedback link to tell Apple this is a total bullshit decision: [https://www.apple.com/feedback/itunes.html](https://www.apple.com/feedback/itunes.html)

<comment><USER9> Choose "request an app" there.

</comment></comment><comment><USER10> What? I really looked forward to this.

Gaming in the apple eco system is horrible already but not even be allowed to stream?

Extremely stupid, Outright hostile

"Business conflict"? Now Apple suddenly becomes a real obstruction in my life and ultimately an enemy. This is switch to android level of bad.

<comment><USER11> _stupid... hostile... a real obstruction in my life... an enemy_

I think I'll clip and save this comment to demonstrate to my students the definition of an "overreaction."

<comment><USER12> I'll not save it, and continue labeling any business entity that obstructs any of my freedoms for profit as an enemy.

</comment></comment></comment><comment><USER13> I don't actually see it happening, but it'd be nice if Valve just released the source code and let people compile it for themselves.

I don't think there's any "secret sauce" in the Steam in-home streaming that's actually proprietary/private. It's just a H264 video stream in one direction and controller button presses in the other, over a custom made low latency protocol.

Given Apple and Valve seemed to be working together to bring VR to the Mac recently, I'm surprised they weren't given any leeway at all.

<comment><USER14> Theres even an open-source version in Java called Moonlight or so.

<comment><USER15> I believe Moonlight uses Nvidia's GameStream protocol, so it's not quite the same (you need an Nvidia card to use it).

<comment><USER14> You're right, I confused those two.

</comment></comment></comment></comment><comment><USER16> Like many other time this has happened, I expect we'll find out that everything we've heard in the first 24 hours was incomplete or just plain wrong, and in a few days this will all get resolved.

Of course the angriest out there will simply claim it was the result of Apple buckling to public outcry rather than self-correcting over a mistake or misunderstanding, but then those people will always choose to see malevolence in any corporate actions they don't like.

</comment><comment><USER17> They've just made a huge mistake. Upset the hardcore gamers market to stop essentially a remote desktop app?

<comment><USER18> I guess the problem is the store. The app allows to access valve's store (which is far cheaper than games in the apple store). If they remove the ability to buy games I am sure the remote desktop app would be ok.

I am guessing anyway

<comment><USER19> I have a hard time with this explanation, as the Steam Store is already available through the iOS Steam app which is available on the Apple app store.

<comment><USER20> You can't buy games using the Steam Store app.

<comment><USER21> You can buy games with the existing Steam app. I do it all the time during the sales.

<comment><USER20> My bad, I remember trying to before and being unable to, I just assumed it would be the same situation as the kindle app.

<comment><USER22> You can't buy games that are in the iOS store from within the Steam app

</comment></comment></comment></comment></comment></comment></comment><comment><USER23> Apple, pissing off game developers since 1976.

<comment><USER24> Also nobody seems to care about the app developers who probably spent months developing this app, to see it go to waste over a bussiness decision.

<comment><USER25> While I'm a bit sympathetic with the devs here, they got paid, and this was always going to be a risky proposition. They must have known that.

Adding the 3rd largest app store in the US to iOS was always going to be a seizmic shift on the App Store and could cannibalise large parts of the iOS game category.

</comment></comment></comment><comment><USER26> I've been saying this for years. There needs to be big scary button with lots of warnings that allows the users to download and run whatever binary they want. That should be guaranteed by law for any turing machine.

Curated stores are a great idea but there has to be an alternative.

<comment><USER27> It all comes down to who owns the machine. In this case you are really just leasing it from Apple.

</comment></comment><comment><USER28> Maybe some mid-level manager at Apple is trying to get a promotion with this.

"Look at how loyal and useful I am to the company. I saw this revenue- threatening thing in the news and I killed it."

<comment><USER29> You'd think they would've blocked e.g. Netflix and such as well (esp. from the Apple TV), given how those payments go around Apple as well. Actually there's probably an agreement between those parties somewhere.

</comment></comment><comment><USER30> I've been waiting for a company of this to just go full litigation as a result of something like this.

The lack of a premium "please give us a representative we can negotiate this with and get an actual explanation from" tier is a serious problem.

</comment><comment><USER31> I'm not sure anything has angered me as a long-time Apple fan (seriously, since 1984) this much (because I've also been a gamer at least that long).

This is some creepy-[girl/boy]friend level of control.

Congratulations, you've succeeded in pissing off any Apple fan who enjoys gaming while thinking that a PC app running on the phone with some amount of latency and resolution loss (not to mention likely illegible onscreen UI elements depending on how things are rendered) is somehow going to compete with a native iOS app.

</comment><comment><USER32> [https://github.com/moonlight-stream/moonlight- ios](https://github.com/moonlight-stream/moonlight-ios)

<comment><USER33> I'm really looking forward to this on the Switch once the hacks start to solidify

</comment></comment><comment><USER34> Considering Valve's recent shenanigans regarding visual novels, it's hard not to laugh about this. As the RPS article put it: "Ah, it's terrible when a digital store approve your products then turn around and removes 'em."

</comment><comment><USER9> Apple seems to be confused. To use this app my PC (or Mac) must be running the game and I must be in the same LAN. How is there a business conflict?

It's not like mobile games are competing with desktop games.

</comment><comment><USER35> Apple is wrong here.

</comment><comment><USER36> The need for decentralized and functional app stores are more real than ever.

</comment><comment><USER37> This is why I'm so excited for WASM: the tech is great, but its ability to break down barriers to entry to markets for new and upcoming players is what makes it socially meaningful and worth supporting.

</comment><comment><USER38> Apple continuing to chase revenue from apps and services really worries me.

</comment><comment><USER39> Previous discussion here:

[https://news.ycombinator.com/item?id=17149470](https://news.ycombinator.com/item?id=17149470)

</comment><comment><USER40> Interesting, since chrome remote desktop is there which (I assume -- never used it) would allow you to remote-desktop into your computer and run steam.

</comment><comment><USER31> As an apple user and gamer, this angers me.

</comment><comment><USER41> I don't think this will last for long...

</comment><comment><USER42> Guess Im done with apple

</comment><comment><USER43> I would switch to iPhone if Apple weren't like this.

</comment><comment><USER44> Can someone please update this to the canonical non-amp URL:

[https://www.theverge.com/2018/5/24/17392470/apple-rejects- va...](https://www.theverge.com/2018/5/24/17392470/apple-rejects-valve-steam- link-app-store-ios-game-steaming)

Apart from not supporting googles effort to control the web, the amp page loads _slower_ than the original and has a ridiculous "cookie agreement" with a button that doesn't work.

<comment><USER45> This page is hosted by the verge themselves so has absolutely nothing to do with Google trying to control the web. It also does not load slower.

<comment><USER44> The _concept_ of amp is google trying to control the web.

Also, my understanding is that all amp pages have to load the _required_ js from an amp project cdn, which is ultimately a google cdn.

And yes, it most definitely does load slower for me - I have nothing but a blank white page for several seconds.

<comment><USER46> >And yes, it most definitely does load slower for me - I have nothing but a blank white page for several seconds.

This is quite obviously an error state, likely caused by an extension of yours. Have you tried using Amp in a fresh install of a different browser? Using different network settings?

It seems very likely that you are the reason amp doesn't work for you.

And this is coming from an amp hater.

<comment><USER47> The issue is that for some reason amp usually seems to block the content from being displayed until the javascript loads, which strikes me as the exact opposite of what an "accelerated mobile page" should do (almost like it was designed by an advertising company wanting to discourage ad blockers...). You can bypass it by activating reader mode in your browser.

<comment><USER48> Not only that, but AMP pages are _only_ potentially perceived as 'fast' when you access them through google's search. When you do that all the AMP links' assets are pre-loaded in the background so it seems fast when you click through. But AMP pages themselves are just the same speed as anything else or slower when access without google's monopoly position pre-load.

</comment></comment></comment></comment></comment></comment><comment><USER49> Wow, when trying to access this from the EU, I'm blocked by this huge pop-up telling me to either accept their tracking or fuck off. The cookie policy makes no mention on how to access the site without clicking "I accept", it just directs you to optout.aboutads.info.

[https://i.imgur.com/dK73MUi.png](https://i.imgur.com/dK73MUi.png)

Is this really GDPR compliant?

<comment><USER50> No. Basically the GDPR is structured around a whole bunch of reasons why you might _need_ to store and process data about people ("Subjects"), for which you have implicit permission because it's necessary to something you're doing for the Subject. You need to make sure Subjects can find out what you needed, and why, and you can't change your mind later.

These purposes do not need Consent. You don't need to Consent to a retailer knowing your credit card number when you use the card to buy something. You don't need to Consent to Amazon knowing your delivery address when you buy stuff.

Consent comes in when you and the Subject both want to enable processing that isn't necessary. For example, if I buy a book from Amazon, it makes sense that I'd get a confirmatory email saying I ordered the book, and they're agreeing to sell it to me, and another one saying the book has been shipped and will be with me in 2-4 days. Those feel pretty necessary. But why would I get email about how great Amazon's new Fire tablet is? Well, Amazon could try asking me for Consent to send that sort of crap to me.

The GDPR is clear that you can't insist on implied Consent, you can't have "By visiting this web page I consent" or "To stop receiving our marketing, just unselect the default-selected boxes in the marketing permissions sub-section of your user profile, this may take up to 400 years to take effect" or similar nonsense. It needs to be a clear informed choice to give you this extra permission.

Some of the specifics will get litigated. I'm sure somebody will try to claim it's "necessary" to their business to track people and sell everything they possibly can, and I expect European courts to decide that's laughable nonsense.

<comment><USER46> >I'm sure somebody will try to claim it's "necessary" to their business to track people and sell everything they possibly can, and I expect European courts to decide that's laughable nonsense.

Who pays the verge for the reporting that you wish to read?

Is this verge reporting on this article made for free, by a volunteer, etc?

Or were they paid?

OK, so the Verge is a business, who has to make money.

How do they make money? Are you paying them to read this article? No?

So they sell advertisements to make money to show you content.

" I'm sure somebody will try to claim it's "necessary" to their business to track people and sell everything they possibly can"

In this case, tracking you through cookies for advertising purposes seems to be a "necessary" part of the verge, as it is literally a core aspect of the monetization strategy to offer free content in exchange for tracked advertising, as they explain in the pop-up.

No ads = no content. I can't see a European court claiming that Europeans have a right to free content in violation of the monetization strategy of the author. At the end of the day, verges servers are private servers and you do have to agree to their terms of use before connecting to their servers. In this case, the terms of use of connecting to a verge server for free articles is advertising tracking.

Good luck suing them, but what would be the end game? Ruin their business model?

<comment><USER51> Newspapers and magazines have sold advertising without individual reader targeting for years and it continues to be a viable business model. Individually tracking users is not necessary.

<comment><USER46> >Newspapers and magazines have sold advertising without individual reader targeting for years and it continues to be a viable business model

Newspapers and magazines charges a subscription. Are you suggesting we should now charge Europeans a subscriptions where we do not for others? I'm ok with that. Don't want tracking? Then give me your credit card and subscribe, or there's the door.

Plus, nearly all newspapers are in economic free fall, advertising was completely destroyed by the internet, and there are almost no newspapers which are in the "green" without having an internet product or being owned by a larger corporation.

<comment><USER52> > Then give me your credit card and subscribe, or there's the door.

I don't understand this type of thinking from some of the posters here on HN, as if GDPR is right now personally affecting you in a negative way. It's a very aggressive way of writing and I've seen a few posters comment in this way.

If you want an example of a company that does non-personalised advertising and is successful: DuckDuckGo.

<comment><USER46> How do you know I am not personally affected by freeloaders who wish to steal content from me and use laws as justification for their entitlement to free no-strings access to my work?

That's very presumptuous.

<comment><USER52> a) If you were, you would have mentioned it by now. Your name appears all over this thread, it's incredible how much GDPR has aggravated you.

b) If you _are_ running a website and don't wish us 'thieving Europeans', then don't allows traffic from Europe.

This is the perplexing thing about your seemingly apoplectic rage on this topic. There are options available for these companies who still want to track people individually.

Calm down.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER44> I commented two hours ago asking for the URL to be set to the canonical one not the amp one.

It's been upvoted at least 40 times, but appears at the bottom of the comments and is collapsed-by-default.

What's the deal, HN?

<comment><USER53> Probably because it's off topic meta noise, like complaints about paywalls. You'd probably be better served by emailing email@example.com.

<comment><USER44> I mean, the URL _was_ changed, it seems. I was more questioning the ghosting of the comment in spite of upvotes, _without_ any kind of notice/reasoning.

"Troll" comments get removed with an explanation.

<comment><USER54> Yes but when something is obviously off topic, that should be explanation enough. On HN we try to respect readers' intelligence and make no attempt to spell everything out, which would be tedious.

</comment></comment></comment></comment><comment><USER55> I can already hear the Apple apologists defending them, something about Valve not adhering to the highest standards and best quality, some BS like that.

<comment><USER5> Unfortunately Apple has to enforce the technicalities around their rules for apps or they legally won't be able to enforce them at all. I wouldn't be surprised if a revised version of the app ends up making it to the store.

</comment></comment><comment><USER56> I am not really suprised by this, buying games and then play them outside of the appstore is not exactly in the spirit of the apples guidelines.

This is clearly different from a remote desktop app.

I'm 100% sure this would be allowed back in if they built it without the ability to make purchases...

Not saying I agree with it but a Company such as Valve should know this is going to happen.

<comment><USER57> Apparently, Valve told Reuters it had disabled the in-app purchase options, and still got canned.

[https://uk.reuters.com/article/us-apple-steam/apple- blocks-s...](https://uk.reuters.com/article/us-apple-steam/apple-blocks- steams-plan-to-extend-its-video-games-to-iphones-idUKKCN1IQ09D)

<comment><USER58> But GP was _100%_ sure!

<comment><USER56> Haha! 50% of the time I'm right 100% of the time!

If they are blocking the app and there is absolutely no way for people to purchase and play games then I think apple are in the wrong.</comment></comment></comment></comment>


The high level API s**t is what's killing the (Firefox) platform - <AUTHOR> http://www.downthemall.net/re-downthemall-and-webextensions-or-why-why-i-am-done-with-mozilla/ <comment><USER2> I don't think a rant from last year has much value. And it's worth noting that DownThemAll is being ported to WebExtensions after all:

[http://www.downthemall.net/progress/](http://www.downthemall.net/progress/)

The WebExtensions API isn't frozen for all time. I'm sure if the DownThemAll developers get involved with specifying and designing the APIs they need then Mozilla will consider and add that functionality in future Firefox releases.</comment>


Levenshtein automata can be simple and fast - <AUTHOR> http://julesjacobs.github.io/2015/06/17/disqus-levenshtein-simple-and-fast.html

<comment><USER2> Not to bring up our previous discussion again, but your complexity analysis is still misleading. Your "O(length of string) version" takes O(length of string) _per step_ , not for the total time. To match an entire word (which you have to do to ensure that you have a match), you have to call step O(length of word) many times, so you're back to quadratic complexity.

Also, it would have been nice if you had done your analysis with k as a variable instead of saying linear when you actually mean "O(nk) for a very small k". Furthermore, if you have a maximum edit distance k, you can also implement the dynamic programming approach for a pair of strings in O(nk) time [1].

Still, your description prunes the trie nicely. It's a nice and simple method that's a lot faster than the naive implementation and good enough for nearly all applications. Have you done any benchmarking by any chance?

[1] A quite fast C++ implementation I wrote is at [https://github.com/xhochy/libfuzzymatch/blob/master/src/libf...](https://github.com/xhochy/libfuzzymatch/blob/master/src/libfuzzymatch/levenshteinLimit.cpp) \- the repo will at some point in the future also contain other, faster methods for calculating Levenshtein distance.

<comment><USER3> > O(length of string) per step

The big win here is not that it's as fast as the optimal algorithm (it's not), but that it's nearly as fast and vastly simpler.

You're technically right that the given code is O(n^2), but the optimization discussed later in the article can easily be applied to turn that into O(nk). Further, for the lucene problem, k=2. That's small and effectively constant, making it "basically O(n)". That's still theoretically worse that optimal, but in practice it just doesn't matter. Even with the slightly slower algorithm, Lucene's cost of searching should be dominated by repeatedly _using_ the DFA and not by _building_ it.

What's really important is that the O(nk) construction algorithm is much simpler than the optimal version. I don't know what the Lucene guys were originally trying to do, but if they had figured out this method instead, they could have avoided the super complicated implementation of the true O(n) algorithm.

> you can also implement the dynamic programming approach for a pair of > strings in O(nk) time

Yes, but that's for every pair of strings you want to test. A DFA costs exactly as much to build as solving a single problem with DP, but when a large number of pairs all have one string in common (the query string), a pre-built DFA can be used repeatedly in only O(n+k) each time. Of course, whether that's enough to make a practical difference depends on the problem at hand.

</comment></comment><comment><USER4> Can someone explain what a DFA is?

Edit: DFA stands for deterministic finite automaton.

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

</comment><comment><USER5> BTW, here are some implementations of the algorithm they seem to have had trouble implementing, in java;

[https://github.com/universal-automata/liblevenshtein- java/tr...](https://github.com/universal-automata/liblevenshtein- java/tree/master/src)

Note there is also an algorithm in the same paper to do the calculation _without actually constructing the automata for it_ , which is even cooler

There are other implementations of the algorithm, like Moman, etc. (I believe Lucene eventually used Moman as a reference implementation to implement it)

The paper is certainly "not easy" to understand, but it's doable.

<comment><AUTHOR> I think that is an algorithm from a different paper, namely this one: [https://www.fmi.uni-sofia.bg/fmi/logic/theses/mitankin- en.pd...](https://www.fmi.uni-sofia.bg/fmi/logic/theses/mitankin-en.pdf)

It looks like that is still quite a bit more complicated; 40 lines vs 40+ _files_ ;-)

<comment><USER5> That one may be (I think this is the later 2004 paper by one of the same authors), but Moman definitely is an implementation of the algorithm they did (it turns out they mention this in a different blog post).

</comment></comment></comment><comment><USER6> The title is a reference to Russ Cox' excellent article (series) on implementing regular expressions:

[http://swtch.com/~rsc/regexp/](http://swtch.com/~rsc/regexp/)

</comment><comment><USER7> It's fun to think of the regular expression which matches all strings off by Levenshtein=1. For "hello" it's something like: hello|ello|hllo|helo|hell|.hello|h.ello|he.llo|hel.lo|hell.o|hello.|.ello|h.llo|he.lo|hel.o|hell.

This seems pretty easy to generate the NFA for this, then compile it to a DFA as usual.

<comment><USER8> Or: hello|.?ello|h.?llo|he.?lo|hel.?o|hell.?

<comment><USER9> That doesn't match "helloo".

</comment></comment></comment><comment><USER10> Thanks a lot for the follow-up/expanded article, jules. The previous discussion was a bit hard to follow for me.

</comment><comment><USER7> Why not generate an index containing all strings + all strings off by Levenshtein distance 1 (or N)? This is what I assumed google would do, but I don't know the index size.

<comment><USER11> Because that is absurdly large, and gets larger as the character set grows.

<comment><USER7> Yeah, realized this later. Maybe the trie (or whatever) index can have a concept of "any single character" built in to it. This should be easier than making into a full automata.

<comment><USER5> [http://blog.notdot.net/2010/07/Damn-Cool-Algorithms- Levensht...](http://blog.notdot.net/2010/07/Damn-Cool-Algorithms-Levenshtein- Automata)

See the part about how you would intersect a trie and a levenshtein automata and find the ones that must be in both. It's not as hard as one would think

(Tries are already DFA)

You can also do it for other types of indexes.

</comment></comment></comment></comment><comment><USER11> Alternative version:

You build the DFA on-the-fly from an NFA built on-the-fly. Also reasonably simple, and it doesn't require building the entire DFA unless the entire DFA is actually needed.</comment>


Europe was the birthplace of mankind, not Africa, scientists find - <AUTHOR> https://www.telegraph.co.uk/science/2017/05/22/europe-birthplace-mankind-not-africa-scientists-find/ <comment><USER2> This is misleading & false. Genetic evidence has conclusively proven our roots are in Africa. While the bone finds are real; the entire interpretation and situating of those finds are incorrect. (I do human genomics for a living).

Their interpretation of geology is also incorrect. The saharan sand comes via winds & continues to do so; making the Mediterranean soil very fertile:

[https://www.washingtonpost.com/news/capital-weather- gang/wp/...](https://www.washingtonpost.com/news/capital-weather- gang/wp/2018/03/26/photos-dust-from-the-sahara-has-turned-the-snow-orange-in- russia-and-eastern-europe/?utm_term=.dda3ecf2937b)

<comment><USER3> > Genetic evidence has conclusively proven our roots are in Africa

No, it did not. I didn't see any proof of that. Or is your proof the fact that you work with the human genome and we must believe you?

The whole African origin theory rests on the fact that the oldest bones are there and so the Homo erectus came from there.

If they would find homo erectus bones that are 1 million years older in China then the theory will change.

<comment><USER4> > No, it did not. I didn't see any proof of that. Or is your proof the fact > that you work with the human genome and we must believe you?

I mean, I certainly trust an expert more than someone with an unhealthy amount of distrust in experts..

</comment></comment></comment><comment><USER5> Interesting, but what's to say we won't find older hominid bones in Africa next year? Is it wise to be so certain that Europe was the birthplace of mankind based on a single discovery? Really, the same goes for Africa. Why are we deducing that each oldest bone means _that_ is where humans came from?

<comment><USER6> Also, when we say the birth of "mankind", do we mean Homo Sapiens, or the Homo genus as a whole?

</comment></comment><comment><USER7> Is Evolution still a thing? Who cares where humans came from.

Elon Musk will merge you with an AI if you can afford that and you will be part of the new Techno sapiens species.</comment>


A dentist made a game in MS Paint and it's terrifying - <AUTHOR> https://www.engadget.com/2019/09/20/world-of-horror-junji-ito-hp-lovecraft-hypercard-game <comment><USER2> For anyone else wondering, the art was made in MS Paint, the game itself was not made in MS Paint. I thought it would be like one of those Turing-complete Excel spreadsheets.

</comment><comment><USER3>
        uMatrix has prevented the following page from loading:
        https://guce.advertising.com/collectIdentifiers...

And there seems to be no easy way to visit the original link regardless. I'm not sure I like this behavior of uMatrix...

<comment><USER4> [https://web.archive.org/web/20190920203125/https://www.engad...](https://web.archive.org/web/20190920203125/https://www.engadget.com/2019/09/20/world- of-horror-junji-ito-hp-lovecraft-hypercard-game/) works for me

</comment></comment><comment><USER5> MS Paint is probably one of the most used programs for drawing pixel art, so the article title seems a bit click-baity and out of context.

</comment><comment><USER6> something is fishy</comment>


Migrating from Redshift to ClickHouse - <AUTHOR> https://www.altinity.com/blog/migrating-from-redshift-to-clickhouse <comment><USER2> Cool to see ClickHouse get some interest here. Been using it for about a year now and consistently impressed with the performance on analytical queries across very large (1b+ rows) tables

Couple pain points though:

* Integration Maturity - Many tools/services either don't have integration with CH or are missing features

* User Management/Security - Have to configure users in their custom XML format, only applied at database level (no table level or row level option), and doesn't plug into SSO, LDAP, etc.

* Getting "current state" for a table - e.g. some table has users and some attributes, harder than it should be to get the "current attribute value" for all users, to do analytics on

* Log Format - very challenging to pull into log aggregation tool and get helpful information from

</comment><comment><USER3> > Reasons to move to ClickHouse

> the [VACUUM] process requires an outrageous amount of time

As of Dec 19 2018, Amazon Redshift now runs VACUUM DELETE automatically, and has been made drastically more resource-efficient [1].

> There are no queries in Redshift that take less than a couple of seconds.

This is likely due to incorrectly-tuned Workload Management Queues. In addition, as of Aug 8 2018, Redshift automatically enables short query acceleration [2], which should speed up short queries by default without additional tuning.

> According to our calculations, deploying ClickHouse on AWS instances with > the same resources was exactly half as expensive.

You also need to factor in the cost of migration (two full-time specialists, three months effort), and ongoing support effort needed to maintain the now- custom system.

Plus, it sounds like some (possibly similar?) cost savings could have been achieved simply optimizing the existing Redshift cluster:

> We can't make a straight comparison about query speed because the data > schema changed so much. But many queries sped up simply because less data > are read from the disk. Truth be told, we should have made this change in > Redshift, but we decided to combine it with our migration to ClickHouse.

In short, continue testing assumptions and tracking updated feature-sets on a regular basis- valid reasons to move to ClickHouse yesterday may no longer be valid today, or at some point in the future. Also, don't double down on sunk costs- it might make sense to migrate back to Redshift in the future, if your issues with the system are eventually improved or resolved. Or maybe not, depending on your use-case.

[1] [https://aws.amazon.com/about-aws/whats-new/2018/12/amazon- re...](https://aws.amazon.com/about-aws/whats-new/2018/12/amazon-redshift- automatic-vacuum/)

[2] [https://aws.amazon.com/about-aws/whats-new/2018/08/amazon- re...](https://aws.amazon.com/about-aws/whats-new/2018/08/amazon-redshift- automatically-enables-short-query-acceleration/)

<comment><AUTHOR> I think the authors were up-front that some of the issues they encounters (for example table optimization) could have been done in Redshift.

What I found intriguing about the cost savings was that it was achieved on Amazon as opposed to going on-prem where you can push costs down further especially if the workload is reasonably stable. It's therefore likely that there are still substantial savings that can be squeezed out. That gap gets bigger if you scale to large cluster sizes.

In thinking about costs it's also important to remember you can run a data warehouse perfectly well without a cloud management plane. It really depends on the data warehouse complexity, how many other things the team has to manage, and their comfort level with the technology. Redshift--to its credit-- has so changed the conversation about data warehouse operation that we tend to forget this.

Disclaimer: I work for Altinity and the article came from our blog. We did not write it and the authors are not customers.

</comment></comment><comment><USER4> Clickhouse is a fantastic piece of engineering but really needs work on the operational and maintenance side. Replication, backups, updates/deletes, etc are very rough and a big obstacle for greater usage.

That being said, even a single server can be many times faster than other data warehouse solutions if your data fits.

</comment><comment><USER5> I love clickhouse: it's simple yet flexible enough and free software.

I'm migrating a lot of data to clickhouse on clusters of servers.

One of the unexpected gains is how it uses far less disk space, which means the data can be put on a few NVME in RAID10, which provides speed benefits even for data that can't fit in memory.

I am now also considering ClickHouse for "cold storage": either by compressing the directories or leaving them as such on a smaller server.

Being able to standardize on one thing for both production and storage would be nice.

<comment><USER6> Can you share results what is the space consumption difference for your data ?

<comment><USER7> Not the poster above, but using Clickhouse for similar purposes (archival/analytics on huge data that started out in MySQL and gets imported to Clickhouse for the long term). Some real-world numbers on our end for the same time period, roughly 2.5 billion rows:

InnoDB Barracuda - (logical data + indexes 583GB, physical ZFS LZ4: 386GB, ~1.51x compression radio)

Clickhouse MergeTree - (logical 349GB, physical ZFS LZ4: 279GB, ~1.27x compression ratio)

The MySQL version of the data has a few different compound indexes which certainly contribute to the size difference, but regardless Clickhouse is dozens of times faster on complex queries against this data.

We run both our MySQL and Clickhouse servers on ZFS (Clickhouse accesses its datastore over NFS on a 10gbit link... in practical terms we have not seen a severe performance penalty for doing this, even though we know it isn't encouraged by the Clickhouse maintainers).

<comment><USER5> [my numbers match yours]

It's very interesting that we made more or less the same choices: NFS on a LAN for cold storage. In practice, I haven't seen performance penalties either. I will certainly standardize on that.

If needed, 'reviving' the cold stored data is as simple as copying it to other machines-- which will also offer sharding.

My only reproach is that servers have to be identical, as clickhouse doesn't seem to be able to take into account the speed differences. My backup servers are quite different from the production server, but in an emergency I'd like to use them all.</comment></comment></comment></comment>


How a false start could help us win - <AUTHOR> http://blog.fulldemand.com/

<comment><AUTHOR> Ours is a case of knowing when to pause, and how to become fanatical about customer development.</comment>


Amazon, Texas Reach Deal to Settle Sales-Tax Spat - <AUTHOR> http://online.wsj.com/article/SB10001424052702304811304577369943403829820.html

<comment><USER2> I hope Illinois learns from this.</comment>


Microsoft give start-ups a leg up  - <AUTHOR> http://news.bbc.co.uk/2/hi/technology/7711211.stm

<comment><AUTHOR> _"... When the start up leaves the programme, either by staying in business for three years, being acquired or surpassing the revenue limit, they will owe Microsoft a $100 (£62) fee and then transition to the normal licensing fees for the software they continue to use ..."_

Is this a sort of cheap MSDN arrangement. I don't understand why anyone would want purposefully use MS toolset for a Startup - unless you are Xobni trying to bridge the desktop email gap.</comment>


What is the best way to shoot an instructional video for my startup? - <AUTHOR>

I am looking to get some screen capture software, and film myself going through the site.<p>What are some tips on creating this demo/instructional video? <comment><USER2> Is this purely instructional or is there a marketing purpose for it as well?

If it's marketing then I suggest: Music, Voiceovers, Pan & Scan, and Ken Burns effect.

For the most part software videos are boring, I'd rather put my hands in boiling water than watch yet another railscast.

Add music thats exciting, and nothing with words in it. Go to your local broadcasting school and find some students to do the voiceover work. Lastly, get some other students to do a decent job of editing the clip so that the focus is on where the action is, pan and scan around the app to create the appearance of motion, etc.

See Google's parisian love as an example of how to make compelling software videos.

Or conversly: Epic meal time, where cooking meat is made _somewhat_ exciting <http://www.youtube.com/watch?v=gpKtarjTvqU></comment>


Getting into Linux Kernel Development - <AUTHOR> https://www.cyphar.com/blog/post/getting-into-linux-kernel-development <comment> vezzy-fnord In all honesty, if you're only a beginning OS hacker, you probably shouldn't be diving into the Linux kernel unless you have a keen specific interest in it. Besides all the complexity, both intrinsic and accidental from its adoption by many heterogenous parties with different interests, it just isn't architecturally interesting.

You want something to broaden your horizons, and that has a much smaller surface. Try Minix 3, Plan 9 (or the 9front fork), DragonFly BSD, Genode, Haiku (BeOS-like), some flavor of illumos, HelenOS or even GNU Hurd.

Besides the easier entry and the higher learning opportunity, you have more of a chance to make truly major contributions. Something like porting your favorite package can get your hands dirty quickly.

Arguably, having less conflict of interest from corporate benefactors makes for a much smoother communication experience, too.

<comment><USER2> This does not make any sense. Any modern kernel(including the ones you mentioned) is going to be complex. The only way to get started is to dig in. Even if you do not make changes right away, trying to understand the code is a reward in itself.

I also don't get your point about conflict of interest. There is no one corporate sponsor of Linux. And just because you are a newbie, your patch is not looked down upon. There is a great community willing to help if you put in the effort.

<comment><USER3> A while back I did some fooling around with eCos, and wanted to add a floppy driver. I looked at the Linux one, some from BSD, but settled on the Minix code: it was a _lot_ simpler and easier to understand. I'm sure it was less efficient, and handled far fewer weird corner cases, but it was just a matter of a day or two of hacking to port it to eCos.

It really depends on your goals - if you just want to learn, then Minix is pretty good.

<comment><USER4> Minix 3 is quite efficient. I would suspect that the complexity comes from the design choices of each OS. Monolithic kernels tend to be more complicated to be maintained than microkernel OSs.

</comment></comment></comment></comment><comment><USER5> There is also [http://eudyptula-challenge.org/](http://eudyptula- challenge.org/) which might help in familiarising with the codebase in sequential steps.

<comment><USER6> IMO the issue with the Eudypluta Challenge is that they focus on the wrong part of kernel development (I couldn't get past one of the first few stages because I couldn't figure out what kind of semantics they wanted for the Makefile -- something that isn't a problem for most kernel development work). Kernel development is mostly modification of existing source code, not the creation of new modules (unless you're adding the support for a new driver).

But yes, anything like that does help familiarise you with the semantics of writing kernel code.

<comment><USER5> I agree. But there are some people(like me) who like a more structured approach, at least initially. I am no kernel developer, so can't comment in that respect with the right technical know-how, but for learning something new, a sequence of challenges is quite good for me to get my feets wet.

</comment></comment></comment><comment><USER7> As a step 0, people may also be interested in working through Linux From Scratch where you compile your own kernel, set up the file system and create your own Linux distribution.

</comment><comment><USER8> I didn't see a link to Aleksa's patch set, so here it is for those curious: [https://lkml.org/lkml/2015/2/22/204](https://lkml.org/lkml/2015/2/22/204)

<comment><USER6> I'll update the post to include it, but the actual merged patchset is this one: [https://lkml.org/lkml/2015/6/9/320](https://lkml.org/lkml/2015/6/9/320). This is the first part which was merged separately in 4.2: [https://lkml.org/lkml/2015/6/5/857](https://lkml.org/lkml/2015/6/5/857).

<comment><USER8> Ah, my bad. So the patch set I linked is something that is still being worked on or just didn't get merged yet?

I was a bit confused as the patch set I linked to were from Feb 2015

<comment><USER6> That was the first version. There's quite a big difference between that version and the one that got merged (it underwent a complete rewrite because the original version was _insanely_ unsafe -- I'm surprised it even worked on my machine).

</comment></comment></comment></comment><comment><USER9> This site is really difficult to read on mobile devices (profile photo overlaps first paragraph of text, paragraphs are very narrow due to large padding/margins). A couple of little fixes would make it a much more comfortable read.

<comment><USER6> Yeah. I should get around to doing that. I'm not a web developer by trade, so I've always felt iffy about doing responsive designs. :/

<comment><USER9> Feel free to reach out if you need a little help fixing the mobile usability issues - I'm happy to give some advice. I'm not a designer by trade but there's nothing huge to fix there - a few small tweaks to the existing design would make it readable on mobile.

And for new projects, a quick CTRL-Shift-M in Firefox while you're creating your stylesheets would help verify that things you're adding won't break on mobile.

(Sorry if I'm sounding negative, but your post might be really good and some small design tweaks would make it readable on any screen size and help stop the design getting in the way of your content).

<comment><USER6> I just fixed it by hiding the image and fixing up the padding on screens <1000px. That makes it look fine on my phone screen. I'll take a closer look at it later.

</comment></comment></comment></comment><comment><USER10> The article links to Linux coding style guide: [https://www.kernel.org/doc/Documentation/CodingStyle](https://www.kernel.org/doc/Documentation/CodingStyle) which has some snarky comments. Is it written by Linus Torvalds?

<comment><USER6> `git blame Documentation/CodingStyle`

<comment><USER11> That's not helpful in this case. Most of lines points to 1da177e4, which is:

        commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
        Author: Linus Torvalds <firstname.lastname@example.com>
        Date:   Sat Apr 16 15:20:36 2005 -0700

        Linux-2.6.12-rc2

        Initial git repository build. I'm not bothering with the full history,
        even though we have it.
        ...</comment></comment></comment>