Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

As I understood signed exchanges, a correct implementation makes it impossible for the intermediary to inject, alter, replace, or otherwise swap out any part of the page without failing verification. This would mean the original server gets to do all the branding and get all the recognition and integrity in transit that its controllers might wish.

I've clearly missed something. Can you help me?



Yes, as you say, Integrity is preserved. However, Confidentiality is also another important aspect of Information Security. Making a 3rd party appear as a 1st party, is a privacy and confidentiality violation, which is why I do not like AMP and signed exchanges.


Yeah, as near as I can tell signed exchanges are essentially a caching proxy. With integrity checks, so that you don't have to trust the proxy all that much and its agency is much reduced. I'm reminded of apt.

The calculation appears to be that given the chance, some website controllers will choose to trade confidentiality of public pages for better load times. In business terms, this seems a pretty straightfoward win in many cases, so I can see why some would sign up.


The publishers are not mentioning to the visitor they are adding one more third party looking at your data; one that maintains an ad exchange and will be an intermediary on every resource request.

A publisher is free to switch to AMP, but choice needs to be given to the user to agree or leave the site the same way it happens with cookies. I wouldn’t opt in and now I cannot block Google tracking at the DNS level thanks to this.


Publishers can, and should, always make visitors aware of how many third parties are positioned to see all visitor data.

We are, unfortunately, a long way from this being normal. Even as third parties doing things like running CDNs or doing TLS termination for other reasons has been pretty thoroughly normalized. Though offering it as a Firefox extension could be an interesting exercise.

I think publishers view AMP as a question of their sovereignty and choice. Since it's their website that's being potentially served by Google, it's their choice to make. There's absolutely a lot of room to dispute if this is the morally correct stance, but I also think it's not wildly out of line with other questions publishers weigh in choosing what they serve and how.


> I wouldn’t opt in and now I cannot block Google tracking at the DNS level thanks to this.

How do signed exchanges break blocking Google tracking at the DNS level? You already need to have google.com unblocked in order to get a results page that serves an exchange from Google.


AMP already heavily restricts what the original page is allowed to put inside, including things like ads, javascript and branding. You can be certain anything google implements around this proposal will have similar very tight restrictions.


That's definitely a scary thought! Can you share any details of what must be public plans to strip everything non-Google of branding? Surely there must be something out there beyond the IETF docs for the protocol, where I don't see any evil plans to Googlify everything in. If anything, it looks like a design intended to allow relaxing the restrictions imposed by AMP.

Perhaps I need to read them more closely.


If you want an honest discussion try toning down the smarmy bullshit.


[flagged]


Your priors are terrible. Extrapolation from past experience is a perfectly valid form of reasoning: it's called “induction”, and most people consider it a valid form of reasoning.

https://en.wikipedia.org/wiki/Inductive_reasoning

Or, to mirror your tone:

Being paranoid does sound like an issue! However, just because other people's personal incredulity hasn't been a great form of evidence in the past, that doesn't mean it isn't a good form of evidence at the moment. Got any reason to believe it isn't?


I understand that a lot of people genuinely do not trust Google. It's been their experience, and thus their priors, that Google is attempting to assert control over all aspects of the web.

Perhaps someone can find some evidence that allows for deductive reasoning on this subject. I would really like it. Otherwise, all we've got is competing lines of perfectly valid incompatible inductive reasoning. Then people choose the one they like or fear the most.

That's a scenario that my priors suggest is not likely to be useful for producing valuable models of the future. Instead, it's a scenario where the primary outcome I expect is for confirmation biases to rule the day.


> Perhaps someone can find some evidence that allows for deductive reasoning on this subject.

Such evidence would be admissible in a court of law, and would probably lead to the breaking up of Google (and Alphabet, and various holdings) under antitrust. Yes, that'd be nice, but you're asking for a lot; even given the premise, it's unlikely to materialise until the statute of limitations has passed, if that.

> Otherwise, all we've got is competing lines of perfectly valid incompatible inductive reasoning.

Not quite. Because you can ignore the lines of the reasoning, take into account the evidence, and then come to a conclusion yourself. If you don't quite trust yourself to do it properly (and who would, honestly? the bias you've highlighted is enough on its own, and it's just one), there's mathematics to do so: Bayes' theorem. (Of course, you have to estimate the conditional probabilities properly, but I find it easier to notice when I'm leaning on the scales when there's a level of indirection like that.)

Most predictions are made with inductive reasoning. If your comment doesn't contain some flaw (even if not the one I pointed out), then it suggests that predictions should be much harder than they actually are. Super-predictors should do not much better than chance. And yet, we find that, in reality, even the little-trained masses do pretty well: https://predictionbook.com/predictions You can see confirmation bias in the graph there, but it's not as significant as my model of you expects.




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

Search: