Hacker Newsnew | past | comments | ask | show | jobs | submit | more ItsABytecode's commentslogin

I think iMessage is a great example of “Embrace, Extend”. Apple didn’t build a standalone chat app because everyone (in the US) was already using SMS on their phones and “hey if you happen to be SMSing another iPhone user you get these extra features”


This hacking is more DMCA than CFAA


By “private API” do you mean undocumented public API?


yes.


I've used 'private API' exactly how you did and some pedant told me it wasn't a real term so I empathize


HN is accessed via an undocumented public API that you are using every time you visit this site.


And I would suggest it's a bad idea to base your entire business off using that API.


So no 3rd party client software unless the company running the service gives explicit permission?

No 3rd party batteries in devices or 3rd party ink cartridges either


It generally doesn't cost e.g. the printer manufacturer anything when you use a 3rd party cartidge. This is separate from the value/loss described above. I still think once you reach a certain size there need to be some interop requirements though but I can also see why many would say these points are unrelated to iMessage.


> So no 3rd party client software unless the company running the service gives explicit permission?

That's about the strength of it. Unless the protocol is open, paid or otherwise. iMessage is closed and undocumented.


I feel like “email is dead as a decentralized protocol” is paradoxically a meme among Gmail users. Counter-anecdote: I haven’t touched Gmail in years and I still send and receive email fine


Yup, I too receive spam just fine. Greylisting and SPF alone doesn't stop it now. If I want to send e-mail to someone on gmail or office365 it usually ends up in spam.


I’ve never really understood the difference between a gift economy with the expectation of reciprocity and a regular non-gift economy


In a regular economy, every exchange is a two-way transaction. I give you something, you give me something (usually of perceived equal value).

In a gift economy. I gift you something. You gift someone something. That someone could be me, but if I don't need/want anything you need, then you just gift to someone else. If there are gifts going around all the time, all in good faith, then most people will receive what they need.

You see gift economies in families or friends all the time. People help others according to their abilities. My rich friend takes me out to an expensive dinner, poor me gets us lunch from that famous food truck. I nurse my uncle when he breaks his leg. He lets my brother's son to live with him for free during college. There is no accounting of how much anyone gave. Just give what you can.

I recommend reading Cory Doctorow's novel Walkaway which describes gift economies beautifully.


“From a content discovery standpoint, I’m really interested in how we can seed conversations and seed experiences with really high-quality content — certainly, editorial publisher content”

I’ve been waiting so long for my mastodon conversations to be seeded with high quality editorial publisher content


> Also, Let's Encrypt security is a joke - they issued fake certificate without serious checking. Using unencrypted HTTP for confirmation is a vulnerability

They can’t use HTTPS if you don’t have a certificate yet


This doesn't mean you should use unsecure methods instead and issue certificates to anyone capable to do MitM.


How could Letsencrypt even verify a server setup if not via DNS/HTTP? Also, verify against what? The servers are basically random strangers without identity when they first talk to LE.


In this case there has been a valid certificate for the site; this alone should raise suspicion.

Also, if they cannot do secure validation then maybe they should stop issuing certificates for sites that already have a proper certificate.


This happens all the time when a server is rebuilt from scratch - same cert using a different keypair.


So should we conclude that SSL cert infrastructure is completely compromised and now any country can issue fake certificates?


No, there is no reason to jump to such extremes.


There are approximately 10 Tier-1 ISPs through which majority of Internet traffic passes, and unless I misunderstood something, they can issue valid certificates for almost any domain. To me it looks like "completely compromised".


Every CA can issue valid certificates for every domain? And it always has been that way.


CA has a risk to get their root cert removed from browsers; ISP doesn't risk anything especially when asked by the govt.


They risk having their peerings cancelled. Also it might be a crime in some countries.


Over the DNS challenge, of course.


This is exactly the same as all other CA's do this.... for DV-certificates you basically place a key/special file on the webserver, or receive a verficiation code via (plaintext) email.

For EV certs there might be more validation, but users will never see the difference between EV and DV certificates.


So SSL certificates are completely unreliable; we should only wait until Russian or Chinese comrades find a good use for this attack (e.g. temporary redirecting Western traffic using BGP to validate a Let's Encrypt's cert for Western site).


yes? this is a well-known problem, which is why CAA-ACME etc and certificate transparency logs exist.


They’re probably thinking of shared hosting environments that don’t have the SQLite library for PHP installed. That seems like a concern you could raise about any database connector, though


It would be pretty hard to find one without the mysql connector


I do love telling users to RTFM as soon as they open the box. In some way I'd prefer that to today's "What manual? You don't need a manual"


Yes, I didn't exactly think it was bad!

It's a bit forceful but it tells you clearly exactly what you need to do to have a good experience. Given the setup was presumably a bit fiddly this seems much better than having customers get frustrated before resorting to the manual.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: