Hacker News new | past | comments | ask | show | jobs | submit | more kalmi10's comments login

I remember reading that card transactions have different costs aspects for the parties involved depending on if the card is actually physically present at the time of purchase. And iirc Apple managed to convince the banking sector that Apple Pay is equivalent to chip card security, so that they get better rates.

According to reddit, Apple Pay works on jailbroken devices, but still, something like this might be at play in all the other similar scenarios.


> According to reddit, Apple Pay works on jailbroken devices, but still, something like this might be at play in all the other similar scenarios.

I can confirm that Apple Pay works on my jailbroken devices, and as far as I can tell, no jailbreak has managed to affect the Secure Enclave.


   > And iirc Apple managed to convince the banking sector that Apple Pay is equivalent to chip card security, so that they get better rates.
As far as I aware that's because Apple actually have hardware-backed implementation so tokens (or signatures or whatever, I honestly have no idea how they called for NFC payments) are generated on iPhone itself. Google on other side just keep few tokens on Android device, but they are actually pre-generated on Google servers.


Interesting. In NZ about 5-10% of places seem to disable contactless payments in an effort to cut costs (most corner shops), while chip+pin works for as little as $1 payment.


The thing I worry about with IPFS is privacy. If you use IPFS directly (as intended, not via a public gateway), and you visit a site, then you are automatically going to be seeding (like a torrent) the visited content, and thus you will be announcing/broadcasting the fact to the world that you (your node/your IP) have visited it. My current understanding is that this cannot really be avoided, since one needs to be able to find the nodes that have the content for any given hash.


IPFS really needs onion routing built-in. When I was reading this, I thought about running an IPFS node on my desktop but remembered it doesn't have onion routing built-in. So I'd have to run a proxy like torsocks and torify the IPFS server. Then I have to worry about all the ways that IP can leak from this. Then I have to figure out how to connect to other IPFS nodes through TOR. So forget it, I'll do it when I have time, which is the same thing I said the last time I thought about running an IPFS node.


At that point aren't you looking for Freenet/Zeronet?


Well, one can use IPFS through Tor, and use gateways that are Tor onion services.


We do this for OpenBazaar which is built on top of ipfs and it works great. We built a Tor transport for libp2p, which is what drives ipfs's p2p networking so any libp2p app, including ipfs, can work over Tor.

https://github.com/OpenBazaar/go-onion-transport


Indeed. And that's where I first learned about IPFS via Tor.

It was y'all that actually got IPFS working via Tor.


Obfuscating your IP doesn't solve the problem. If a malicious actor knew someone's info (such as address), they could give them an ipfs link with CP and report them.


Sure. You also gotta hide your name, address and all other information that could identify you. Otherwise, there's no point in obfuscating your IP.


What is the legal standard for say YouTube about not carrying illicit content? Just follow that. Make a list of banned hashes or something of the sort.


there's something weirdly poetic of having information reborn through voluntary noise


Good point about the experimental Tor support and the Onion IPFS gateways.

Is there a reasonable way to use untrusted gateways while upholding the data integrity guarantees? I think it should be possible in theory.


Because data on ipfs is content addressed by hash you can always check the integrity of data you receive, in theory, although the tooling isn't there for you to easily verify the output of a gateway without your own ipfs node afaik.


The other potential possibility/issue that I would be uncomfortable with, would be a bad actor visiting and then seeding my content. Say someone also seeding or just locally having child pornography or some other nefarious thing, and now they are also an aggregator for your non-nefarious content. Just the possibility of that type of potential unintended association gives me pause in terms of considering it for a blog or whatever else.


I got a downvote so I guess people aren’t concerned about this or believe my concern not valid or naive?


It doesn't seem meaningfully different from a bad actor having, say, a tab with your Wordpress blog open on their computer.

Or to pick something closer to the point, someone seeding a copyrighted film and also a Linux distribution. That sort of coexistence has gone on for many years without causing problems for the legal uses of torrents.


Thanks for the feedback. I get your point there. It feels much different though. A tab open is completely read only, and they are not aggregating your content. I guess I just don’t like the idea of seeding my content and not knowing who or what the the “seeders” might also be involved with. I guess purely an ethical concern/decision on my part in likely choosing never to use a seeding technology to serve my content.


That almost seems like a slippery slope. I mean, your site’s content could now just end up sitting on some CDN server or proxy alongside something nefarious, without IPFS and you’d have no idea.

I’d have the same objection if the seeder was voluntarily choosing what to seed for that express purpose, but I don’t know that it should apply if the seeding is just an automatic part of how the network operates underneath.


> I got a downvote

Have another one for complaining about it. Wear most with pride and some have been proven to be well deserved. Let history be the judge rather than your fragile ego hey.

Otherwise feel free to go back to Reddit.


Maybe a software delay where it only starts seeding 5 minutes later, or an opt-out button where you can avoid re-seeding if you don't like what you see.


Or perhaps better would be random seeding of additional content you didn’t view.


This is a good idea - my only worry is you might end up unintentionally seeding illicit content like CP


IPFS isn't designed for private communications. It's designed for highly decentralized publishing of content. Safe, in this context, means the data is safe to "be".


I understand that no one is going to tamper with the data. Everybody (who is running a full node) is gonna get what they ask for, but then they are gonna go and announce it to the world that they have it, and that worries me privacy-wise.


> that worries me privacy-wise

This should be addressed by the client, not the server. The server's function is to serve the data, not serve data and pretend it doesn't know who it gave it to.


Since IPFS is peer to peer, who is the server in this context?


Honestly I think the simplest and most effective method is to keep things as they are and have archive.org/.is keep backups of websites. A backup on archive.org is much more likely to stick around after 10 years than the users seeding a file.


Not if there is a government issued takedown notice it isn't.


IPFS has the same problems given a takedown notice[0]. Although you could continue serving the content and convince others to serve the content, any entity can take the next step and go after you.

[0]: https://github.com/ipfs/notes/issues/284


This also seems to be true in theory regarding torrents but not in practice.


I found this in the FAQ:

If I want to share a calendar with my spouse, do I need to get two subscriptions? No. You can just create a normal subscription for yourself, and an "Associate" subscription for your spouse. Then share the calendar with the second account, and that's it. However, Associate accounts can't create their own calendars. So in order to have a personal calendar (that you can't see), your spouse will have to get a normal subscription too.


The sites still get your UA. This was about your DNS server getting your UA.


Somewhat unrelated, but the first time I bought something in a physical store in the USA, i thought i was being ripped off, because the final price came out different than the one that was listed next to the item. I had no idea that it was standard practice to exclude taxes from the displayed price.


Yeah that is bullshit that should have been stopped 50 years ago.



It's not like interoperability suffered because of that. HTTP fallback was always there.


Nevertheless it's some kind of fait accompli, especially in a market with only three main actors.

Where one actor can also start using the new "standard" overnight and break lots of services for people which are not using their browsers... You know what I mean. It's some kind of enforcing to have a monopoly.


.. so you can live swap routes and endpoints even with dynamic routing (without performing any hot-reload dance in your own code), which actually sounds like a neat feature at first.


Strange thing is that I never intended or expected my regular ad blocker to skip Spotify ads. I just kinda noticed one day that there seems to be more ads on mobile, and I left it at that. Then one day I noticed a bug related to looping on the desktop web client, and while trying to figure out what's going on.. that's when I finally realised that my regular ad blocker is skipping Spotify ads, and is messing up looping in the process.

So.. I guess there might be others who are kinda unintentionally blocking Spotify ads too. Terminating accounts without warning for people who are not even aware that they are in the wrong is gonna result in backslash, I think.


Agreed, this exact same thing happened to me before I upgraded to a premium account. uBlock Origin is always on for me and set to noscripting, so I was really confused at that bug. I assume that they'll implement some sort of warning system though.


I guess some would prefer not to lose their sometimes elaborate music libraries, playlists, likes, history, recommendations, friends, etc..


Join us for AI Startup School this June 16-17 in San Francisco!

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

Search: