On Wed, Sep 3, 2014 at 3:48 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote: > Guido van Rossum writes: > > > lot: five years ago (when I worked at Google!) it was common to find > > internal services that required SSL but had a misconfigured certificate, > > and the only way to access those services was to override the browser > > complaints. Today (working at Dropbox, a much smaller company!) I don't > > even remember the last time I had to deal with such a browser complaint > -- > > I would tend to discount your recent experience, then. Smaller (and > possibly even more important in this fast-developing area, younger) > organizations are a lot more nimble about things like this. > As a defensive data point: I don't remember a single instance of this happening for Google internal services, at least since I arrived in 2007. I'm not doubting that Guido remembers some thing(s) but in general people here at Google would not stand for that, then or now. I would not call it common, especially five years ago. Common things I _have_ encountered over the years everywhere I've been both internal and external: services that listen on the https port 443 but don't have a valid cert as they are intended only for http port 80 access. Those are becoming somewhat less common, the only thing I regularly see that on anymore is random home router web config UIs as issuing a signed server certificate for security hole ridden commodity embedded box is... a challenge. (I'm not commenting on the PEP plans as it seems the right things are happening for now) -gps @ Google -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20140908/c3ee635f/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4