HTTPS should be the default for Racket package directory Web and
webservice requests, and for any Racket server stuff that *requires*
privileged access -- just as good practice, on balance.
After that point, however, the recent calls for "HTTPS everywhere" by
well-meaning people (and perhaps a few non-well-meaning people) become
more complicated, with adverse privacy implications that might not be
intuitive at first. (This domain is much more complicated than
thwarting a casual snoop on open WiFi, or thinking that server operators
would actually be permitted to thwart the enn-ess-ay. And I see at
least three big privacy downsides to "HTTPS everywhere" that can further
the goals of the big commercial privacy adversaries, as well as those of
state actors. I'm not including better-known flaws of the current HTTPS
SSL trusted certs approach in the three downsides.)
These assertions of downsides are a good puzzle for students to
solve... Two of the downsides will become obvious once you understand
the ways contemporary commercial snooping happens -- which understanding
includes examining what you can of the real-world practice yourself,
since little is written about it, and also disregarding most privacy
activists. The third downside might require learning about general
desired capabilities of privacy/security adversaries, and considering
that currently mitigating realities that will come to mind will be
affected by where some of the browser developers are now going with
internal security robustness.
Neil V.
--
You received this message because you are subscribed to the Google Groups "Racket
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-dev/5676F932.5020109%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.
