7,098 karma · joined August 17, 2007
Life at Low Reynolds Number makes you think of things which arent visible but move :https://www.damtp.cam.ac.uk/user/gold/pdfs/purcell.pdf
There are more but lets see if the above two work for you first
The name of the root is to indicate ubiquity, not to provide identification of the CA who is operating it. If you need to know whether a cert will work on an older platform, you look at the name of the cert embedded, not the serial number. Its faster and easier to do so. You also want to know when things will expire and when you might need to migrate CAs. That’s best done with the name of the root. Plus – this is how browsers track which roots are trusted. Browsers could tie to the serial number, but they use the subject info of the cert for identification purposes on what roots are included and what roots are audited.
In summary, he has misguided notion about why these values are in the certs and the value they provide. He sees no value in them because he assumes people will be looking at the ICA and root purely to contact the CA, when that is rarely the case. I dont think there is a security or real issue with the information.
Akamai acquired RedSwoosh precisely on the same economics promised and if this were economical/viable they would already have deployed it, no?
I did hack with Travis on RedSwoosh code base optimizing his TCP Zipper algorithm which was pretty cool BTW
Hmmm. So there lies the rub that we dont know as of now (will try to write an extension as you said)
Does this extend to other thick client apps like SAP or even ftp just for thinking's sake?
>This information stored should obviously not be time sensitive. But if you're >running a client for social networks or such, it's perfectly a good idea to cache >the last 10 posts seen for example, so that when the user loads the page, he >instantly has something to look at while the browser is fetching the fresh >content.
Correct but now this is why I say an API because each app can have its own way of caching the last few items (http objects, files, posts whatever might be tagged)
>One key consideration is security: do not cache things on the browser that may be >private or sensitive information, unless encrypted, but even then the argument >could be made to not do it at all. That said, storing your application graphics >and most of the UI bits in local storage can certainly improve the user >experience greatly.
Is it because of the browser? Say I remove it out of the browser and place it somewhere else, encrypt it store it and wont display until I verify the end user with SSO etc, would that take away this concerns. Depends on the user(most UI bits I agree need be cached and harmless either way) for what bits might be cacheable
May I ask whats the equivalent for it in Chrome as majority of users are on Chrome for me.
>> as my enterprise I want to push objects to my employee's cache using an API
Well, theoretically you can do it using Service Workers today (https://developers.google.com/web/ilt/pwa/caching-files-with...) but I want to do it in a automated way so that I minimize the thundering herd when everyone comes tomorrow on Monday morning apart from enabling an offline experience (users in some countries have crappy connections so asynchronously pushing it is a way to solve it)
>Combine it with some basic packet capturing of new TLS connections and I could push arbitrary JS that did event capturing on all the sites that employees visited.
Hmm..I need more on this but the idea is they are SRI checked and come from a supply source thats trusted (but I get your drift on solar winds kind of lateral attack), but if I am right then what you say can even be done with the service worker API I mentioned above
Correct but do you know of any way to look at the cache hit ratio, stuff that didnt fit into the browser cache and other stats? I understand you can do it on a page level but I want to accumulate all of sessions and look at it aggregate and yet to find a easy way to see under the hood
>Make sure as much of your corporate intranet stuff as is reasonable counts as >same domain for purposes of cache sharing, and standardize on a single version of >your frontend libraries, etc, and you might actually get cache hits naturally. >Standardizing frontend libraries is hard, but if shaving the couple of ms here >and there is important, I'm sure you can find a way.
Correct but there is no guarantee its in the cache whereas my effort is to publish my app's shell/versions of frameowrks before I enroll users to my app
>Now, maybe you've got a lot of work from home with terrible networks; that's >pretty common today, or maybe you're work from the field and have had terrible >networks forever. In that case, it might make sense to do something like wrap >your web pages in electron where all the html/css/js is included and you only >need to fetch data and you've got full control over the caching. Nobody on HN >likes electron, but it would solve your enterprise problem. You might consider >actually making an application, but that's unfashionable these days.
Now, this is new, I need go learn this electron thing
- "Be Here Now" by Ram Dass (read once and listened to audiobook twice)
- Flatland by Edwin Abbot Abbot --> read multiple times to understand whats going on in different levels
- Some PG Wodehouse stuff because it ages well (specifically the bibilical references)
- Midnight's Children by Salman Rushdie which is absolute verbal wizardry
- Treasure Island by RLS which is a kids favorite for adventurism